Skip to main content

Implementing PM: It

Implementing PM can be quite a challenge in any organization. There will be a need to put a lot of processes in place, there will be a lot of reporting, there will be training, there will be software implementation, and there will be a significant investment made. Senior leadership has to see a return on investment (ROI) for all of this. Showing an ROI will generate support for the effort. When you begin to sell project management in your organization, you need to be aware of whom the stakeholders are. A list of stakeholders and issues that you should consider are identified as follows:

Stakeholders
  • To have a successful implementation you must have senior level buy-in. Get a C-level officer to sponsor the PMO or authorize the resources to be used for your project management initiative.
  • Consider the structure of your organization. Start with the organization chart. Break down the business units and get their leadership endorsements.
  • The workers in your organizations want to be successful. Offset resistance to PM by rolling out project management in as non-threatening a manner as possible. Let them learn the methodologies of project management – and terminology – before you throw out to many comments like; “get the WBS done, establish an EV measurement system, show me the IRR for the project”. The bottom-line is if they feel comfortable with what is asked of them, they will support your effort.

Methodology

  • There are many ways to slice a loaf of bread. But from an organizational learning aspect – pick only one way. The Project Management Institute has the internationally accepted methodology for project management. The methodology described here follows the PMI’s PMBOK.

Tools

  • There are numerous project management software products on the market. You should select the one that interfaces best with your other software products and applications. You should also consider the size of the project. Some products are better suited for larger projects, while they may be overkill for smaller projects.

Training

  • Developing a curriculum for project management should be done in parallel with establishing a methodology. The methodology cannot be implemented effectively without a training program. Deciding how much training, for whom, when and how are major concerns when making a training decision. Methodology that is proprietary and vendor specific should be avoided. The PM methodology from the Project Management Institute is methodology with the widest acceptance around the world. Look for training that supports the PMI methodology. Some initial questions that should be answered are as follows:
    • How many employees do you have to get trained?
    • Are they geographically dispersed?
    • Do they travel?
    • Do they need to get PMP certified?
    • Has a PM methodology been identified in your organization?
    • Do you have a budget for this training established?
  • These are questions that you should be prepared to answer before selecting a vendor. Do not under-train or over-train your workforce. Match the training they need to the jobs they will be performing. It is important to prepare the employee for their duties before they are in the position where they require the skills.
  • In order to communicate the methodology used for project management, we must train our workforce. This should include the following:
    • Sponsor training for senior management
    • Project management fundamental training
    • Extensive and specialized project management training
    • Advanced project management training
    • Program and portfolio management training
    • Tools and software training
  • Training will enhance the probability of success for the PM initiative. Start by removing the culture that fears the change or acquisition of a new method or tool. Do this by developing your workforce competency towards the new method or tool. As they learn they will develop confidence in their abilities to utilize the new knowledge and skills.

Maturing the Project Management Initiative

Organizations must not only say that they are implementing project management, they must embrace it. This is done through a commitment throughout the organization. The following issues must be focused upon in order to maximize the ROI for an organization’s investment in project management.

  • Senior level sponsorship
  • The PMO
  • Dedicated project management resources
  • PM methodology
  • Training
  • Systems and Software
  • Measures of PM performance

Senior Level Sponsorship

In order for any management methodology to be embraced the initiative must be endorsed and sponsored by a senior level executive. This can include the CEO, COO, CIO, or CFO as well as other senior level executives in an organization. The saying that it starts at the top is imperative to maximize the effectiveness of project management. With the C-level endorsement many an obstacle can be removed. This C-level endorsement will encourage other senior level executives in an organization to support the program. In addition, you will find funding for various resources to be greatly enhanced for your efforts with project management.

The PMO

The PMO should be the focal point for an organization’s PM initiative. The leader of the PMO should report to either one of the following two options. First, the CIO or the appropriate department where the majority of projects reside. Second, and a better alternative, would the COO, so that they do not have a particular departmental function alignment. The PMO should be responsible for defining the methodology, tools and templates to be used, and oversee the PM training.

Dedicated Project Management Resources

Organizations must allow for resources to be used on projects either full-time or part-time. They can report under the PMO auspices or they can maintain their functional alignment. This will require resource utilization management, so that they are not over or under used. The probability is greater that they will be over utilized. Managing the proper amount of resources that should be allocated can be challenging. This will depend on the workload for the organization.

PM Methodology

The internationally accepted methodology for project management is from the PMI. This organization has been evolving the methodology for project management professionals since 1969. A testament to their global reach is seen in the sheer numbers of organizations that have endorsed their methodology and certification – PMP – and the number of international chapters and certified members.

The methodology that is selected must be standardized throughout the organization. Processes must be defined, documented, and communicated to all concerned. It is imperative to mature project management that project documentation be archived. From this archiving, lessons learned and best practices can be accomplished. We will explore this aspect more as we discuss how an organization can develop maturity.

Systems and Software

There will be an investment for systems and software to execute project management. The capability to share information and communicate is constantly and rapidly evolving. Data can be collected, stored, and accessed immediately anywhere by any member of your organization that you wish. Monitoring, control ,and tools are numerous that can help an organization plan, execute, monitor, and report project performance. These tools must be selected prudently and trained to enhance the success of the project management initiative.

Measures of PM Performance

At the very essences of project management is the project plan. If you do not have a plan you do not know where you are going or at the very least how you will get there. PM performance is based on comparing actuals against the plan. A challenge for many project managers is that they rarely know what an acceptable variance is. Projects will not come in as planned. Imagine a large IT project estimated at $58M and 18 months of effort. Do you agree that it is unacceptable that after 18 months the project will be completed and at a $58M budget? What is the project came in at 19 months and $61M; would this be considered a failure? It all depends, what was the acceptable variance? We truly cannot measure performance unless we know what an acceptable variance is. It is imperative to know this range in order to measure the performance for PM. Techniques such as variance analysis, earned value, BCA, and ROI are measures that we look to in order to determine project performance.

Project Management Maturity Model

Maturity models have become quite prevalent in last 20 years. The software engineering institute and Carnegie-Mellon developed a capability maturity model that was used to assess the maturity of processes used to develop software. The model identifies five levels of process maturity for an organization:

  1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.
  2. Repeatable (project management, process discipline) the process is used repeatedly.
  3. Defined (institutionalized) the process is defined/confirmed as a standard business process.
  4. Managed (quantified) process management and measurement takes place.
  5. Optimizing (process improvement) process management includes deliberate process optimization/improvement.

There are many models with a great level of similarity to the CMM model have been developed over the last several years to assess maturity of project management in organizations. The PMI has led the way with their model called organizational project management maturity model or OPM3.

An organization needs to realize that they must pursue achievement of higher levels of maturity in these models in order to realize greater ROI for their investment in project management. Consider receiving fantastic training received by rave reviews, what good would this fine training be if not applied in earnest on ensuing projects? The benefits realized would be minimal. To truly see the benefits an organization must utilize the tools and techniques they are trained on in order to start towards higher levels of maturity.

Developing Maturity

Step 1. Level I – Initial

Analyzing what your organization is doing in project management. Figure XX identifies the tasks and activities that a project manager performs on projects. Use this to determine what is done at each the project management lifecycle.

Step 2. Level II – Repeatable

Assess the practice and methodology that your organization utilizes as they use project management. Are there tools or techniques they use to:

  • Select a project
  • Plan a project
  • Develop the product
  • Monitor and control the project
  • Close the project

Step 3. Level III – Defined

The following questions will be helpful in assessing if your organization has properly defined practices for project management. Have polices and procedures using the tools and techniques identified in step 2 developed? Is there training and information about how to use these tools and techniques?

Step 4. Level IV – Managed

The use of measurement tools for project performance must be utilized to develop baseline data for project performance. In addition variance management must be deployed to quantify project performance. An organization must define what is an acceptable variance for a project in regards to schedule and budget performance as compared to the project plan. Configuration management will be useful here to ensure that the expectations of stakeholders have been met. Stakeholder satisfaction is a challenge because it cannot be measured in time or cost units. Qualitative data will be valuable as you look to identify the satisfaction of stakeholder expectations.

Step 5. Level V – Optimized

Best practices must be identified in order for an organization to continuously improve what they are doing with project management. Perform a Phillips ROI impact study to determine the ROI for your initiative. ROI will be ultimate evaluation tool to compile the various qualitative and quantitative data needed to ensure that the best tools and techniques are realized to ensure maximum ROI. For more information on ROI please refer to www.VillanoavU.com or www.ROIInstitute.net

Wayne has taught and consulted project management, quality management, leadership, curriculum development, Internet course development, and return on investment around the world to Fortune 500 companies. He has over 26 years experience from the Air Force as a project manager for AF technology training and curriculum development programs. Wayne has developed numerous AF and corporate training programs, classroom, multimedia, and Internet based programs. A dynamic presenter and trainer, Wayne has spoken at numerous conferences such as; the Project Management Institute (PMI®), the International Society for Performance Improvement (ISPI), and the American Society of Training and Development (ASTD) annual conferences. Wayne is a doctoral candidate with Nova Southeastern University specializing in Computer Information Technology. Wayne is certified Project Management Professional (PMP) by the Project Management Institute, a Certified Professional in Learning and Performance (CPLP) by the American Society of Training and Development, and a Certified Return on Investment Professional (CRP) by the ROI Institute. Wayne is currently an adjunct faculty member at Villanova University.


Wayne Brantley, MS Ed, PMP, CRP, CPLP is the Senior Director of Professional Education for the University Alliance (www.universityalliance.com).

Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

In my previous article, Is it Time for the BA and the PM to Get Hitched? I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the BA/PM for lack of an appropriate title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP4O, for short, to support this new professional.

In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure
The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape
At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.


Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

  • Linear or Incremental 20%
  • Iterative or Adaptive 70%
  • Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together
I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.


Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3nd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Managing a Project as a Complex Journey

I decided to mark a pause on my current series on the cornerstones of Lean Project Management to reflect a bit on my current journey to South East Asia and what it can teach us about successful projects and team alignment.

I often compare the management of a project to a journey:

  • the current situation represents the point of departure of our journey (point A),
  • the anticipated end-deliverables represent our final destination (point B), and
  • the project itself represents the itinerary from point A to point B, the journey

On June 24th 2008, I embarked with my spouse on a five-week journey (project or vacation?) to South-East Asia to visit Singapore, Bali and parts of Vietnam. Right from the start of this “project”, we have faced minor difficulties arising from bad communication among the “team members” of this new project and the resulting misalignment of the “project team.” Within the first three days of our trip, we have already experienced three unforeseen events with frustrating affects on our journey and its final destination (the meeting of stakeholders’ expectations!):

  • one team member delayed our flight from Beijing to Singapore by one day,
  • another team member had us leave the Beijing airport, to spend “contingency” funds on an unplanned stay at a Beijing hotel, and
  • another team member just forgot to load our luggage on the rescheduled flight from Beijing to Singapore

Everyone did his or her best and all team members were very considerate and polite with this stakeholder (me!). However, two of the main team members, The Canadian Airline and the Chinese Airline are in a new business relationship that has yet to be clarified in terms of communications between the two airlines, integrated tracking and management of luggage, local regulations and cultural differences. Both airlines did not have the same vision for this project: Canadian representatives had no clue on SOPs and rules used by their Chinese counterparts on transit situations. Actually, the Chinese faced a brand new situation for them when we arrived in Beijing unannounced by Canada (their databases do not communicate). The Beijing team members were unprepared and had different individual ideas on how to tackle this unforeseen situation. Beside this “new project”, “spontaneously assigned team members” had to cater to divergent priorities. Finally, everyone did their “project work” with all the best of intentions, but just ended up along the way failing to meet the expectations of this main stakeholder (me again!) and his now-distressed spouse.

Projects carry the same complexity and issues as a journey to foreign parts. You will have to deal with:

  • different organisational and “silo” cultures,
  • “spontaneous team members” who realise at the last minute that they have to contribute to the project, while having their own recurring concerns to live with and other priorities,
  • team members that are not accustomed to working together
  • communication plans that are, as a result, ill-designed and fail to ensure everyone is aligned towards the same global objective.

Those disturbing ingredients are found in many projects. We focus so much on the destination (the desired deliverables), that we forget we have a whole journey to live and manage together. This journey is only possible if everyone on the team is aligned and shares a common vision, not only on the end destination but also on the itinerary.

One of the major postulates of Neuro-Linguistic Programming is that: “The Journey IS the Destination.” You cannot separate the project itinerary from its end-deliverables. And, in order to achieve project goals, all team members must be aligned to see not only the same destination but also to embark on the same journey. If the journey is a great experience, the destination will be perceived as very satisfying; if it is not, then the destination cannot be savoured to its full extent. Projects are important change inducing journeys. And ultimately these journeys ARE the destination.

While I try to get my luggage back, I invite you to view the last Louis Vuitton publicity on YouTube (http://www.youtube.com/watch?v=hzp_gshdwsM). Journeys, projects are all part of life. Good or bad, they are life itself. So let’s make the most of them by ensuring that team members are aligned and all embark on a same meaningful journey.

Time to Kick Back, Take It Easy

The summer is finally here! This is the time of the year that I try to relax – but I do find it difficult.

This is the time of the year that I plan, meet and regroup. I schedule all my team meetings for the summer months (working around everyone’s holidays) and review the past, look at the current status of work in progress and plan or re-plan the next few months.

I must admit that I do not punch a clock like many of our readers, so I am able to take a few liberties but regardless, for many this is a quiet time and thus a perfect time to regroup.

The team meetings …what did we say a year ago and what really happened? We spend time looking ahead: the business plans, the schedules and the work that is giving us trouble. And we have some fun so there is some team building in there as well.

The planning… where are we going? Is the plan realistic? Are we equipped? Do we have enough time? There is no doubt that we see this as a luxury that we will not have available in the fall – so we appreciate the opportunity.

The re-group …this is where I air some dirty laundry – get the junk out and over with. Do we need to re-jig the team slightly? Are there some weak points? Are we vulnerable in any way? This is the time to go over it all.

And …I take the time to build my forecasts and start my budget process. This may not be the right time of the year for this for some of you, but it may be a good time to look over the plan you set months earlier.

This is a great time of the year for me. I come out of the summer rejuvenated, prepared and re-scheduled. I have a team that thinks I get it. I have a to-do list longer than ever, but that’s alright. I panic when I am out of control. No more panic. I am in total control by the end of the summer.

By the way, I said I took liberties. All of August on my island in Georgian Bay. The wonders of High Speed Internet via satellite!

From Good to Bloody Excellent

I recently wrote here about the lack of strategic value in typical project management organizations. Since then, a few inquiries came in, all asking essentially the same question: “What is your vision for a highly valuable PMO and how do we transition there?” I will attempt to answer this question here, since more than a handful people may be interested. In this entry, I’ll describe the vision. Next time, I will offer some ideas on how to get there.

It has been discussed many times over that there is a continuum of choices when it comes to the model and modus operandi of a PMO, ranging from a highly decentralized community of practice to a centralized professional project management team, which tightly controls execution of all projects within the organization. Whatever form it takes, I envision a PMO that represents a prudent investment, not simply a recurring expense. Let me explain.

In the past few years the Project Management Institute has become the envy of many professional organizations, due to the exponential growth of its membership base. This growth, in my view, has occurred for a few reasons:

  • The PMP accreditation provided an “easy” way for hiring managers and especially HR to qualify candidates, and, hence, gained broad acceptance.
  • Most professionals in such industries as engineering, construction or IT, are charged with running projects at some point in their career. The potential membership base is therefore vast.
  • Barriers to entry are incredibly low and rarely enforced.

Such membership growth may appear to be a good thing but, in fact, it is not dissimilar to a common scenario which involves your holding shares of a public company and the company issuing more shares to finance its operating or investment activities. This is called dilution, which decreases the value of the shares you hold. In the case of the PMI, weak entry controls have allowed many individuals with weak management and leadership skills to enter the profession, driving the expectations of employers down. I know a receptionist with no practical project management experience, who has earned a PMP designation. Today, Workopolis is rife with project management job postings which state that the chief requirement for the job is a familiarity with MS Project or some such tool. What happened to leadership, strategic thinking, contracting skills, or people management abilities? Not surprisingly, the average remuneration has also plummeted: I routinely hear seasoned project managers lament about being offered $60,000 per annum full time or $45/hour on contract.

It seems to me (and this is one time I really hope to be wrong) that more and more, the market views the role of project manager as that of a bookkeeper of sorts, a type who prepares project schedules and shuffles papers. When viewed in such terms, a project manager represents an expense, which everyone should look to minimize. And there you have it – it has already happened, as I mentioned already.

The same idea applies to the corporate PMO. Fill it chock-a-block with bookkeepers from project management, albeit with fancy tools and frameworks, and in the shoes of a C-level executive, and I will fail to see much value in it, but rather an expense I have to carry, reluctantly. Organizations with prudent financial management strive to minimize expenses. That’s a hint.

Organizations with prudent financial management also look for worthwhile investments, and your PMO may be positioned to become one. Here is how I envision a highly valuable PMO.

Appropriate Model.

There is no such thing is one size fits all, when it comes to the PMO. This came out loud and clear, at a panel discussion at ProjectWorld 2008. I was one of the three panelists at that session and the large number of participants reconfirmed the panel’s unanimous opinion on this beyond our best hopes. If the model is not right, it won’t work, period. Which one is right for you is impossible for me to tell without knowing a little bit about your organization.

Competency.

The PMO has a decent level of knowledge, well above the level of PMBoK, in such core management disciplines as strategy, people management, finance, marketing, MIS. It maintains and applies excellent knowledge of project management tools and techniques, and an understanding of their advantages and drawbacks, so that the appropriate ones are used every time.

Business Acumen and Alignment.

The PMO shows excellent awareness of the current economic realities, state of the industry, market conditions and current business priorities. It is fully aware of the corporate strategy and structures its activities so that they further the organization’s positions towards strategic goals.

Presence

Armed with leadership skills and business acumen, the PMO is a key contributor when it comes to the formation of project portfolios, making strategic decisions during the execution of projects, and development of project alternatives. The PMO is not afraid to push back and is highly regarded for that.

Innovation

The PMO is always on a lookout for better tools, techniques and practices, based on its experience and the best industry standards. Its business skills make it possible to suggest to the business, projects and approaches that have not been thought of. The PMO incessantly promotes project management skills within the organizations and acts as a “go to” entity for all questions related to it, thus improving the quality of project management across the whole organization. Is it a tall order; too much to ask for? I don’t think so. Moreover, I am convinced that almost any PMO, with professional help, can be made into an “investment grade” entity of considerable value.

or (905) 278 4753

 


Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company specializing in IT- business alignment and located in Toronto, Canada. Ilya can be reached at [email protected]