During the late 1960s and early 1970s, I taught a course which I designed at the University of Illinois entitled, "Fundamentals of the Space Program for Schoolteachers." The quest to place man on the moon and bring him back safely was discussed everywhere. It was only fitting that this information be presented in an easy-to-understand format to present and future schoolteachers.
I cannot count the number of times that I have been introduced to a person that their company referred to as "one of their best project managers." I always ask myself, "What are the criteria to be the best project manager?" When I interviewed these people and asked them to tell me about their successes, the discussion usually centered around just one project. And then, it is often just the end results and deliverables that they discussed. Of course, this may have been their favorite project from their history of many successes, or perhaps it was the only project that was truly regarded as a success. People have a tendency to accentuate the positive and avoid discussions on anything that can reflect upon them in a negative manner.
For several decades, executives viewed project management as a necessary evil. First of all, there was no guarantee that project management would even work. Some executives even hoped that it wouldn't work. Second, project managers would possibly be making decisions that should be made only at the executive levels. This could threaten the executive's power base. Third, project managers might request a great deal of authority to get the job done, thus reducing some of the existing authority of senior management. And fourth, project managers could become very powerful, perhaps more so than some executives, because of the amount of information they possess.
There is a new word being introduced into the project manager's vocabulary, namely "infographics." Infographics is the displaying of critical project management information onto dashboards so that the client and stakeholders can make informed decisions. This information may appear in a real time format rather than periodic updates. This is the future of project management. For this to work, and work well, there must be an agreement between all parties at the beginning of the project as to what metrics will be tracked and reported. The metrics will be graphically displayed on a project management dashboard as part of client/stakeholder reporting.
Because of my belief in this topic, and my passion for it, I have written a new book entitled, Project Management Metrics, Key Performance Indicators and Dashboards. The book is co-published by International Institute for Learning, Inc. and John Wiley & Sons, and scheduled for release in the 3rd quarter of 2011. The book discusses how project management is being converted from traditional project management to metric-driven project management. In the future, we could easily see each project team having a team member specifically trained in infographics, such that the critical or agreed upon metrics will be easily presented to clients/stakeholders on dashboards. The ultimate goal might very well be paperless project management, which could save companies millions of dollars a year.
Companies will begin collecting project management metrics and creating metrics libraries. Companies have been using business or financial metrics for years, such as market share, profitability, number of new customers and ROI (Return on Investment). At the onset of a project, the project manager and the client will decide which metrics in the library should be used and whether new metrics should be created. The project management metric library could have hundreds of metrics, whereas the business metric library may have less than a dozen metrics.
With this in mind, each issue of allPM.com will have one new metric and an explanation of how the metric can be used. In my new book, I discuss significantly more information than in my column, specifically how the metrics can be related to the PMBOK® Guide knowledge areas and domain areas, colors to be used in the graphics, placement of the graphics, aesthetics of the graphics and accuracy of the graphics. The graphics metrics used in the column will discuss why the metric is used, any limitations that may exist, and what information the metric tells us.
Best practices have become competitive weapons that help companies win new contracts. Let's consider two companies that are bidding on a contract and submit essentially the same price. The first company says that they have a best practices library and will use and share with the client those best practices that are applicable to this contract. The second company has no best practices library. It's pretty obvious who will be awarded the contract.
If you tell the client that you will be using best practices on their contract, then you should validate it through a metric. Otherwise, the client may believe that you lied to them just to win the contract. Sometimes, companies ask the PMO to audit projects to make sure that the best practices are being used.
The figure shown below illustrates a metric that can be used. Let's assume that the company maintains a best practices library that has twenty-five best practices, and that ten of the best practices are applicable to the project. Also, all twenty-five best practices in the library are assigned a number between one and twenty-five.
This figure shows the client that, out of the ten best practices promised, seven were used, two have not been used yet but will be used, and one best practice that was promised will not be used. It is possible that some conditions on the project have changed, thus making the use of best practice #23 inappropriate.
Some metrics are quite complex and transmit a great deal of information. This metric, however, is relatively simple and can build up trust between the parent company, the client, and the stakeholders.
© 2011 allPM.com
For a 20% discount on all advance orders of Harold Kerzner’s ‘Project Management Metrics, KPIs, and Dashboards’ please visit Wiley and, upon checkout, enter the following code: WAXZN
I guess the title caught your attention. Projects do not fail by themselves; they need help. The help they get are called people, more specifically, project managers. Projects that fail can be called people failures; projects do not fail - people fail. When projects fail, we seem to go through meticulous pain to identify every possible cause of failure. A brief list might include:
- End user stakeholders not involved throughout the project
- Minimal or no stakeholder backing; lack of ownership
- Weak business case
- Corporate goals not understood at the lower organizational levels
- Plan asks for too much in too little time
- Poor estimates, especially financial
- Unclear stakeholder requirements
- Passive user stakeholder involvement after handoff
- Unclear expectations
- Assumptions, if they exist at all, are unrealistic
- Plans are based upon insufficient data
- No systemization of the planning process
- Planning is performed by a planning department that may have little experience in project execution group
- Inadequate or incomplete requirements
- Lack of resources
- Assigned resources lack experience
- Staffing requirements are not fully known
- Constantly changing resources
- Poor overall project planning
- Enterprise environmental factors have changes causing outdated scope
- Missed deadlines and no recovery plan
- Budgets are exceeded and out of control
- Lack of replanning on a regular basis
- Lack of attention provided to the human and organizational aspects of the project
- Project estimates are best guesses and not based upon history or standards
- Not enough time provided for estimating
- No one knows the exact major milestone dates or due dates for reporting
- Team members working with conflicting requirements
- People are shuffled in and out of the project with little regard for the schedule
- Poor or fragmented cost control
- Each stakeholder uses different organizational process assets, which may be incompatible with each other
- Weak project and stakeholder communications
- Poor assessment of risks if done at all
- Wrong type of contract
- Poor project management; team members possess a poor understanding of project management, especially virtual team members
- Technical objectives are more important than business objectives
There are actions that project managers take without effectively understanding the ramification of their actions. While the project manager believes that some of these actions or steps are the right thing to do, the results can be devastating for the project.
Step #1: Let's negotiate for the best workers and, if necessary, ask the sponsor for support in this effort.
First of all, your project's cost baseline may not allow for the salaries of the best people. Second, the better the worker, the more likely it is that they will be in high demand elsewhere and the likelihood of you keeping them for the duration of the project is low. They will be removed from your project at the most inopportune time. But the third reason is the worst of all. The best workers always seem to try to gold plate the project with often unnecessary "bells and whistles, thus elongating the schedule and driving up the cost. This has been my experience. Having average or above average workers that can do the job effectively may be best. Average workers tend to look for the quickest and easiest solution to a problem rather than a solution that embellishes their reputation. Perhaps you should look at your projects that had schedule slippages and cost overruns and see if you had the best workers or average workers. Of course, I am assuming that the average workers can do the job effecively.
Step #2: Let's use the power of acknowledgment to motivate the work force.
If you have taken the time to read the book, The Power of Acknowledgment by Judy Umlas, you would know how and when to provide acknowledgment and in what manner. Unfortunately, technically-oriented project managers would never be caught dead reading such a book because it does not require computers, mathematics, or a vast knowledge of Greek symbols. Yet these are the people that probably can benefit the most from the book (Yes, I am an engineer and am proud to say that I have read the book).
Many years ago (or perhaps I should say, decades ago), I was a young project manager managing a multimillion dollar project. At the end of the project, I wrote a letter of appreciation for one of the workers and, in the letter, I strongly recommended that the worker be promoted immediately. I sent a copy of the letter to the worker, his superior and the Personnel Department. Everyone on the team would see that I believe in acknowledging worker performance. In less than 10 nanoseconds, the worker's superior called me up to inform me that this worker that I had recommended for promotion was the worst worker he had ever had and that he would never be promoted. It seems that the worker was in his superior's office almost daily getting assistance on the work he was doing on my project. I learned several hard lessons about acknowledgement from this brutal experience:
- Never provide acknowledgment (or reprimand) to a worker without first checking with the worker's superior to make sure you are in agreement with what is in the letter. There are exceptions, of course.
- Make sure you understand how other members of the team will react if they do not believe that acknowledgement should have been given out to this worker.
- Giving acknowledgment out the wrong way to people that do not deserve it may encourage them to continue doing what they have been doing in the past and not seek to perform better. You have thus defeated the purpose of providing the acknowledgment. The result can be several of the causes of failure identified previously.
Step #3: Don't worry about "time robbers." They won't happen on your project.
If I had to prepare a list of the critical skills for a project manager to have, understanding one's own energy cycle would be near the top. Are you a morning person, afternoon person, or evening person? I am a morning person and believe that I am most productive between 6:00 a.m. and noon. As a project manager, there were many activities that I had to perform myself rather than delegating them to someone else on the team. I would then identify the most critical items and these had to be performed in the morning. Today, most of my book-writing is done in the morning.
It might be interesting to look through the list of failures identified previously and see how many of those should have been done or prevented by the project manager. When project managers do not understand their own energy cycle, they tend to allow time robbers to destroy all of the precious time when they could have taken action to prevent many of the failures from happening. There were early warning signs, but the project manager was so busy that he/she refused to recognize the warning signs until disaster was virtually imminent.
Step #4: Virtual project teams are managed the same was as any other project team.
If you are one of those people that believes that this is true, then career termination is just around the corner. This would be a good time to update your resume just in case...... Well, I think I made my point. When we talk about enterprise environmental factors as we do in the PMBOK® Guide, most people simply think in domestic terms based upon their limited experiences. Managing in global market forces project managers to be more aware of global politics, working with a group of stakeholders from various countries that will probably never be able to come to an agreement, dealing with highly bureaucratic approval processes that require sign-offs by all of the government's ministers, team members that are all working toward different personal agendas that are more important than the project's objectives, and the list goes on..... And, of course, let's not forget that you may have never met many of the people assigned to your team. Project managers that agree to undertake global projects without understanding cultures and politics that the team members must deal with are on the road to self-destruction.
What you see here are four steps, each of which could have led to self-inflicted pain. It is hard to manage a project successfully in isolation. Projects are managed through people. And unless you have a reasonable grasp of the human side of project management, more so than what is taught in textbooks, feel free to send me the causes of failure on your next project so that I can add it to the list.
© 2011 allPM.com