Stakeholders and the Cost of Change

Any individual or organization whose interests may be affected positively or negatively by the completion of a project is called a Stakeholder (SH). He could be a positive stakeholder such as the customer, the sponsor, the supplier, the project manager himself, and he could be a negative one such as the competitor. But how the involvement of these people affects the success of a project, and how they influence the cost baseline as the project progresses.

When I think of stakeholders in any project I immediately link it to the GIGO phrase (Garbage In, Garbage Out). A project is initiated, planned, executed, and closed around the requirements stated, and implied, by project stakeholders. In other words, the project’s success is heavily dependent on stakeholder’s input and involvement. If their input is weak, little, rare, or late in the project lifecycle the end product or service would be a costly ‘Garbage’ gathering dust on the shelf.

SH influence in a project diminishes over time due to the increasing cost spent as the project progresses. Hence, it becomes more difficult to introduce changes as we spend more in the project. So, the Project Manager (PM) should involve SH as early as possible when the cost spent is low.

The earlier and more intensive SH involvement in a project is, the more likely the project successfully finishes within the Triple Constraints (Scope, Time, and Cost) achieving a high quality end deliverable. SH Analysis is a vital tool to be used by the project manager (PM) throughout the project lifecycle, especially in the planning phase, to guarantee meeting his SH needs. With this tool the PM identifies SH influence, interests, and needs. Then he prioritizes and quantifies the needs and then translates them into project requirements stated in the Scope Statement. This is a repetitive activity that should be done throughout the project and according to the Change Management Plan so as to prevent Scope Creep.

Not only does SH Analysis prevent deviation from project objectives, but also it minimizes the risk of cost overrun. If a key SH’s need was not detected early during planning, it may cause rework as well as going behind schedule. It becomes much difficult and costly to rework some activities during Executing due to a missing key SH requirement. Because of that it is a good, and may be a must-do, practice to spend considerable time in planning processes, especially the Scope Management ones to compile a comprehensive list of SH’s needs.

Another important practice to involve SH and to mitigate cost overrun risk is the use of Phase Exit Reviews or Gates in addition to end-of-phase verification process. At the end of each phase in the lifecycle the PM should validate deliverables of the phase against scope baseline and that the requirements to proceed to the next phase have been met. In addition, the PM should seek documented acceptance from key SH on deliverables at the end of each phase through what is known as Scope Verification process.

I would say that sticking to the SH Analysis tool and to Scope Verification process would minimize probability and impact of cost overrun risk and of having a useless end product or service.

Progressive Elaboration

A project is defined as a temporary endeavor undertaken to create a unique product, service, or result. This definition explicitly states two of three characteristics of a project-Temporary (which means it has definitive start and end dates), and Unique (in the end product or service delivered out of the project). However, this definition implies a third important characteristic of a project which is Progressive Elaboration.

If you are reading a book discussing a topic that is new to you, you would start with the preface that gives you an overview about the book’s subject. This high-level synopsis about the book would be clearer to you in more details as you read more through the sequential chapters. At the end, you would find yourself having comprehensive and detailed knowledge elaborated as you progressed in your reading.

Managing a project resembles reading a book in the way knowledge and details are being built up as the project goes on. It means that a project is developing in steps and is continuing by increments. As more details become available as you progress in a project, you update your high-level initial plan and come up with more accurate estimates. For example, if you have a 2-phase project lifecycle (Concept and Design) your first iteration in planning will be some high-level or fairly detailed Concept phase with very few details on the Design phase. As the project progresses you will get more details about requirements that fit into the Concept phase and adds more details to the Design phase, and so on.

Progressive Elaboration characteristic in a project leads to what is called Iterative Processes. These processes result in outputs that feed into other previous processes to update the plan. For instance, when you create the Work Breakdown Structure in the Create WBS process you might end up with some necessary updates to the previously built Scope Statement (during the Scope Definition process). Hence, this output/input update phenomenon from one process to another builds up the progressive elaboration characteristic of projects.

As we can see this feature makes managing projects a flexible and an integrated endeavor. Project management processes work together in harmony to constitute one integrated vehicle that would lead project team to achieving project deliverables within set constraints. However, progressive elaboration should be used with care and according to the Change Management Plan so as to prevent what is known as “Scope Creep” that I will discuss in my coming blogs.

Spirit of PMI

In an earlier blog I discussed the values of being a PMP Project Manager, and in this blog I will discuss the frame of mind all Project Management Professionals (PMPs) have in common which makes them distinguished in managing projects.

Spirit of PMI (the Project Management Institute) is the frame of mind or the mindset or the paradigm through which PMPs manage projects. It is the hat that PMI requires PMPs to wear when managing their projects in order to successfully achieve project objectives. If you read the PMBOK Guide you can feel this spirit throughout the five Process Groups-Initiating, Planning, Executing, Monitoring & Controlling, and Closing.

As a Project Manager (PM) to be a decision-maker is an essential part of this spirit, for instance. Although a PM should share ideas and get input from key stakeholders in arriving to the best decision to take, he should not wait for others to make decisions on how to proceed with the project, and he is the one ultimately responsible for any decision taken in the project.

In another instance, you can feel the spirit of PMI in Scope Management. Creating the WBS (Work Breakdown Structure) is an essential process that must be performed to manage the scope of project. WBS is one of the tools that make Project Management distinguished from all other industries or areas of expertise. Another piece of this spirit is the emphasis on using historical data as input to any new project. As I discussed in my previous blog about Lessons Learned, historical data could be the lessons learned from previous projects that PMs can use to manage their new projects efficiently and effectively.

Stakeholders and Stakeholder Analysis are important aspects in managing projects. PMI focuses on stakeholders’ early involvement in any project. Stakeholders’ needs must be considered and prioritized then translated into requirements. The earlier stakeholders are involved, the more likely the project closes successfully within constraints.

Prevention rather than detection is an important part of PMI spirit. A PM must be proactive. He should analyze and anticipate problems before they occur then take the proper preventive actions ahead of time. He should not wait until problems or risks become issues that jeopardize his project success.

What I mentioned above along with many other topics in the PMBOK Guide compile the Spirit of PMI that gets PMPs together despite the different geographies, languages, backgrounds, and attitudes.

Efficiency and Effectiveness in Project Management

Are you managing your project efficiently, effectively, or both? Are you Doing Things Right, Doing Right Things, or doing both? What a project manager is doing throughout the entire lifecycle of his project is actually increasing efficiency and effectiveness.

Going back to the ABC’s of management, management is defined as planning, organizing, leading, and controlling resources (human and other resources) to achieve organizational goals. This definition implies both increasing efficiency and effectiveness.

Efficiency measures how well and productively a manger uses his resources to achieve goals. Project management places heavy focus on how to acquire the right project team to perform project tasks and to close project successfully within the agreed constraints. For example, in Human Resource Planning the project manager proactively boosts efficiency by deciding on the Organizational Structure and Roles and Responsibilities to complete project tasks, then, when he later acquires project team, he obtains the right human resources according to the Roles and Responsibilities, and he decides on any training needs they may require to complete their tasks. Project Manager should keep an eye on the Resource Availability; are resources Overallocated? Is the Resource Usage curve smooth? Project Manager uses Resource Leveling as a tool to increase efficiency by eliminating Overallocation of resources and keeping almost constant or smooth use of resources throughout the span of the project lifecycle. When it comes to the Monitoring & Controlling phase the project manager tries to increase efficiency by resolving conflicts that may arise within project team, and by reviewing his team’s performance so as to enhance the overall performance of the project.

On the other hand, Effectiveness measures the appropriateness of the goals that an organization is pursuing and the degree of achieving these goals. Again, this is a core measure in Project Management since it is all about applying knowledge and tools and techniques to achieve project goals. Building and measuring effectiveness in a project starts when the scope is defined during Planning phase (Scope Management Plan, Scope Statement, and the Work Breakdown Structure-WBS). Scope is built around goals and end-deliverables the customer or sponsor needs. A solid Scope Change procedure is compiled during the Scope Planning process. Through this procedure scope of project is kept under control throughout the entire lifecycle. At the end of each phase, and before moving to the next phase, the PM verifies the deliverables of the phase against the scope baseline to check whether the agreed upon scope is being met and to verify that the project in total is still appropriate and in line with the overall strategies of the company or the customer. As a result of this continuous control over scope corrective and preventive actions are taken to keep the project focused on the original plan or to update the plan itself to cope with the ultimate goals pursued by the customer or the sponsor.

If you think of efficiency and effectiveness this way you will find that these two measures are pivotal in project management profession. Not only do they apply to the cases mentioned above, but also to all project baselines-Scope, Cost, Time, Quality, Human Resources, and Risk.

Lessons Learned and Project Management

Learning something useful from unpleasant, as well as pleasant, experience ranges from being an instinctive reaction that you can see in children to being a scientific approach that professionals use in managing their work. Learning from experience is proved beneficial in project management and is now considered a must-use in managing projects according to the best practices of project management. PMBOK goes to the extent of considering the project not closed if lessons learned are not documented and communicated to stakeholders.

According to the PMBOK Guide (Project Management Body of Knowledge Guide) Lessons Learned are defined as the learning gained from the process of performing a project. Not only are they identified and distributed to stakeholders at the end of project, but also during the entire project lifecycle and at the end of each phase. This helps improve future phases of the current project as well as future projects coming down the road.

Lessons learned are important input and output of any project. They are part of the organization assets a project manager should use to help him manage his project successfully. If you think of lessons learned as identifying what went right and what went wrong in your project, you will see them take various forms; they could be the ground rules you set to manage your team, or techniques proved effective in resolving conflicts, or recognition events that were useful, or procedures followed in managing virtual teams as well as team building activities.

Lessons learned could take the form of suppliers’ and team members’ performance history that can be used to select the best fit to do the tasks in future projects. Risks and their effective responses are important forms of lessons learned. You can learn a lesson by saving your Microsoft Project plan as Template for future use.

As a project manager embarking upon a new project, imagine that you have been handed all the preceding precious information on a plate from previous projects, how likely will you succeed in your new project than if you do not have these lessons in your hands? How grateful will you be to those project managers who gathered and documented such information? And how strong will your belief be in such a PM Methodology that imposes identifying, storing, and disseminating lessons learned in any project managed under its umbrella?

Manage the “PMO Project”

I have read a story about a company that perceived the PMO function incorrectly and, consequently, deemed it a burden that would do nothing except blowing up its overhead cost with no return on investment.

The story started with an enthusiastic employee in the company who loved the Project Management profession and worked hard to earn the PMP credentials. He encouraged others to follow his footsteps and to become PMP’s. He decided to move on with the new profession and to establish a Project Management Office (PMO) in the company. He initially succeeded in selling the idea to the top management and started to set the PMO up after he had changed his current position in which he served for more than 10 years. He started with selling the idea to other branches of the company through a couple presentations then published the first internal newsletter about PM and the importance of PMO. He compiled a PM Methodology document and published it for people to use.

A few months later the people interested in his work, especially his followers, have not heard any new activities of this to-be PMO. After they contacted the PMO officer they were stunned by the fact that the PMO started to die prematurely. More surprisingly, they received an internal circular that this person (officer) has now been appointed a new position that has nothing to do with PMO! Yes, the PMO officer has changed his career path.

When he was asked about the reasons behind this sudden change he declared that top management had really not been convinced about the idea of the PMO. They claimed PMO would require additional overhead costs that, from their perspective, were not justified especially during times the company imposed cut-cost policies. It would increase manual work. Moreover, executives claimed that their projects do not require a PMO to manage them although they have piles of pending projects.

This story begs the question of who is responsible of this failure in establishing the PMO and selling it correctly to the top management. To me, I would point my finger at the PMO Officer in the first place.

Establishing a PMO in a company is a project by its own. It has to undergo all phases of a project lifecycle. I believe that a thorough feasibility study should precede initiating such a project. This study is the best place to present the values and benefits of having a PMO in place. The project has to have a sponsor who supports the idea and commits to providing the needed resources. Getting the buy-in from the sponsor is not the end of his role in the project. He has to be involved of any obstacles the project manager (in this case the PMO officer) might need help to resolve. In the planning phase of this project the PMO officer should have involved all team members who will participate in building the PMO (other project managers in the company who will eventually be reporting to the PMO). Planning the PM Methodology is the most important part in the project. The PMO officer did not get other members’ buy-in by ignoring their input to the methodology.

The point in this blog is to draw the attention to the importance of using the best practices of Project Management even in establishing a new PMO. It is a project that needs feasibility studies, sponsorship, stakeholders’ buy-in, team members’ involvement, proper planning, executing, monitoring, and closing. If the project fails, it is the Project Manager’s responsibility.

Advocacy of PMP Credential

Recently, I have read many comments and blogs questioning the value of the Project Management Professional (PMP) credentials; whether it really makes a difference in a Project Manager’s career, and whether a PMP project manager is more competent in managing projects than a non-PMP experienced project manager. Hence, I would like my first blog to discuss this issue and to shed some light on the value of a PMP.


For some people PMP is only a certification gained by passing an exam after which one receives a certificate that he frames and hangs up in his office. This is the argument raised by people who really do not know much about PMP. Others argue that having a project managed by an experienced project manager is safer and more likely to succeed than having it managed by a PMP with little experience.


The PMP is not only a certification; it is rather a journey into the Best Practices of Project Management. In order for someone to be recognized as PMP he has to understand and be trained to apply the PMBOK Guide (Project Management Body of Knowledge Guide). This guide is a document (standard) of what is globally recognized to be the Best Practices in Project Management.  There is global consensus by SME’s and PM veterans on the effectiveness of these practices that if applied correctly would ‘enhance’ success opportunity for projects. Hence, through PMP you will learn the shortcut to success. I see PMP as a driving license; unlicensed drivers would probably make more accidents than those licensed ones who learned the rules of the game before being involved in it.


The PMBOK gives project managers the best practices on a plate! It does not however deny the value of experience nor do I. Experience is important in PM, but it remains lacking the best practices. PMP credential is an agreement to consensus on how to initiate, plan, execute, monitor, and close projects. This global consensus is by far better and more effective than individual judgments on how to manage projects.


Some people argue that they have read the PMBOK Guide and they found it not applicable to their industry. Well, I say that the PMBOK Guide is not a methodology on how to run projects in different industries. It is a standard containing processes that YOU need to use when building your own methodology. It is similar to the ISO9001 standard for Quality Management; the standard gives you the clauses needed to build a Quality Management System (QMS) which enhances the possibility of delivering a quality product to your internal and external customers but it does not build to you the QMS itself. Building the PM methodology is the challenge of each firm to develop by adopting the guidelines outlined in the PMBOK Guide. And here comes the role of the Project Management Office (PMO) which I will address in my coming blogs.