Posts Tagged ‘project’

“Would you please help me print out this ‘WBS’? It won’t fit in one page. I have a status meeting with the Sponsor in 30 minutes!” a colleague of mine approached me and asked. “This is not a WBS! It is a Schedule in a form of hierarchal structure.” I said sarcastically when I saw her WBS. She listed all project deliverables, and listed all activities below each one. This is not what a WBS is intended to be used for. Does your sponsor or client need to know how you’re going to complete each deliverable? Do you really need to present a 100+ boxes on your WBS to get your sponsor agree on what’s included and what’s excluded in your project scope? Absolutely not.

The primary benefits of having a WBS in any successful project dictate the need to keep it simple. Firstly, a WBS depicts the boundaries of project scope. A client or a sponsor can easily sign off a well-structured WBS as it includes all project scope and excludes whatever out of scope. Secondly, it ensures that effort is not wasted on unnecessary or out-of-scope deliverables. That is, if the WBS lists a redundant Work Package, this would require extra resources, time, and cost. Finally, a good WBS can be used on a project dashboard to communicate scope (changes) without confusing stakeholders with scores of activities needed to complete deliverables. The latter point is actually the key to build a good WBS. A WBS does not include activities; it only lists deliverables down to the Work Package level. Leave listing activities to the Project Schedule. WBS is composed of tangible deliverables without activities whereas a Schedule describes all activities required to complete those deliverables outlined in the WBS.

From another perspective, a WBS represents the project lifecycle that is different from the PM Process Groups. WBS is not used to chart Initiating, Planning, Executing, Monitoring & Controlling, and Closing of a project. These are process groups that describe how you manage a project from start to end but not what the project includes and what it excludes (scope). On the other hand, a project lifecycle describes the phases into which a project evolves to complete each of the agreed upon deliverables. Hence, one of the most commonly-used WBS’s is breaking down the project into phases, deliverables, sub-deliverables, and Work Packages that collectively constitutes the overall scope of the project.

If WBS represents the lifecycle, how should PM processes be represented as part of the project effort? Project Management is actually a phase in the WBS that has its own deliverables, sub-deliverables, and Work Packages. Taking a software development project as an example, the WBS shown in figure (1) is what is expected to represent the lifecycle and scope of the project (WBS in its initial structure for illustration purposes). 

Figure (1)-Software Development WBS

As shown in figure (1) the Analysis phase of the project consists of two deliverables: Glossary, and Requirements Specifications. The SRS deliverable consists of three sub-deliverables: Use Cases, Supplementary Specifications, and Reporting Requirements. The sub-deliverables can be broken down further into Work Packages (components that can be estimated for required time, resources, and cost). Use Cases, for instance, can be broken down into more specific use cases discussed with customer or user of the system under development.

Although WBS is progressively elaborated (built in increments as project progresses) a PM should make sure her WBS is complete and constitutes 100% of the agreed scope. All phases should make up the 100% completeness of the project. And all child deliverables under each phase should make up 100% of the parent phase, and so on. This is one way to ensure a WBS, so scope, completeness.

After a WBS is structured correctly, a project schedule can be established. From each deliverable or Work Package in the WBS PM with her team members can list the required activities to build each component. Time, resources, and cost are then allocated to each activity of the component after which a project schedule (e.g. MS Project Plan) is generated and schedule baseline is then set.

Advertisements

tightrope-walkerMost of us enjoy watching a tightrope walker in circuses trying to walk along a rope to reach to the other end without falling down. Skillfully, he uses a balancing pole to make it to the other end while being secured with a safety net. Sometimes this walker takes your breath away when he slips off the rope and falls in the safety net, yet, you know that he is not hurt. When it comes to real life and you look around you will see a real tightrope walker in your organization whose slip may cause a disaster not only to him but also to the entire organization. Guess who! He is the Project Manager (PM).

All what a PM does is trying to reach from one end of a project (Initiating), to the other end (Closing) safely by keeping all of the project’s competing demands balanced. What is funny about this, and at the same time challenging, is that most of project stakeholders (SH) know what competing demands are, and they are even skilled at stretching them. All of them know that a PM has to deliver within scope, time, budget, quality, and available resources. However, none of these SH knows what ‘Balancing Pole’ is to use to keep these demands balanced. Even if they know it, they don’t know how to use it. Here comes the role of our Tightrope Walker; the PM.

I will touch on three key management areas a PM uses as Balancing Pole to maintain the balance in his project’s competing demands which are Integration, Communication, and Conflict management areas.

A PM needs to keep his project balanced by keeping it integrated both on technical side and human side. For example, maintaining an effective Change Management procedure enables the project manager to incorporate any requested changes into all project baselines; i.e. if an implemented change affects scope, it has to be reflected to cost and time as applicable. The feedback loop of continuous update to project management plan as he executes the project is another way of integration that maintains a balanced project throughout lifecycle.

Regarding human integration I emphasize the skill of integrating the project team members together to work as one cohesive unit towards one objective. Just like football team players whose coach harmonizes their performance to score goals. For example, building the Work Breakdown Structure (WBS) is an activity that helps the PM integrate his team members as it involves collaborative effort from all of them.

It is said that 80% of projects failure is due to poor communications. A successful PM is the one who continuously maintains links with all stakeholders to satisfy their information needs and to best manage their expectations about the project. Whether it is through effective meetings, presentations, emailing, or conference calling the PM is kept updated with any requested changes that SH need at the right time. Besides, by building an open communications environment a positive constructive atmosphere amongst team members is created where ideas are shared and team work is fostered. All that gives a heavy mass to PM to keep him balanced in the project journey.

Conflict management is directly related to communications skills. A proficient communicator is most probably an effective conflict-solver. It is worth mentioning that mastering the strategies of conflict resolution is a key to maintain harmonized performance in project team. Unhealthy conflicts are disruptive and detrimental to the project. On the other hand, a PM should realize that conflict is sometimes healthy and needed in projects; a project with no conflicts is actually an ‘unbalanced project’.

At the end of the day it is the PM’s challenge to keep the project balanced. The more skillfully a PM performs ‘tightrope walking’, the more he ‘entertains’ his stakeholders and the more likely he makes it to the other end of the rope without falling.

Professionals’ characters are made up of two components; the Technical Skills and the Human/Managerial Skills. These two categories of skills are competing against each other. If someone becomes more of a technical style professional, his managerial style will be affected, I would say, adversely. So, what do we think is the right composite of a successful project manager? Are employers recognizing this important composite character in any Project Manager they seek to employ? And how a technical person can be converted into a good Project Manager?

“A Technical Expert Wanted” is what some job postings should be titled nowadays rather than “A Project Manager Wanted” especially for employers who do not appreciate the 80/20 skill composite of a Project Manager. To me, it is disappointing to see a posting seeking a project manager while more than 90% of the job requirements are in technical specialties and only 10% are of human or managerial skills! If the first and foremost job requirement is someone who has 15+ years of experience in a technical specialty, then you need a technical expert or a SME who will be inundated with solving and dealing with technical issues during the project lifecycle. Well, then who is going to manage your project; manage your team, manage your stakeholders’ expectations, and balance your project’s competing demands of scope, time, cost, quality, HR, and risks? Who is going to keep integrity and harmony amongst team members to achieve project goals? Who is going to communicate and report on performance? The answer is “Mr. Project Manager” but not the one you are seeking in your posting. Both PM and SME would never exist in one person. So, if I were one of these employers, I would seek two posts; “A Technical Expert” and “A Project Manager”, but I would never jeopardize the success of my project by asking for a Project Manager to play both roles.

Best practices show that a successful project manager has to have his skills composed of at least 80% human and managerial skills and at most 20% technical skills. I believe that bringing a project to success is a collaborative effort in which all stakeholders are involved. If stakeholders do not find the Leader to inspire and integrate them to achieve the project’s vision, the project would fail. This challenge for a PM is not achieved by sitting for hours and hours in a closed room solving a technical problem in the project, it rather is achieved by living the project with team members. Hence, communications is the paramount skill a PM should possess.

Having said that, a technical person can be a good project manager by acquiring the right managerial skills required to lead his project team. On the other hand, he should be kept away from being involved in technical issues, and even not leaving a room for him to be attracted to technical issues. Some good employers assign each project manager up to 4 projects at a time rather than having him manage one project and doing other technical tasks. By this they help him build up his human and managerial skills that are precious to their projects success.

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.

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.

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.

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.