In spite of an increased focus on competency in PM conferences, journals and online knowledge sources, organizations continue to experience project failures at the hands of incapable PMs.  

Identifying common negative behaviors that can contribute to these failures might be the first step towards recovery:

1. Communication imbalance – communication consumes a significant percentage of a PM’s time so one would assume that this is a competency that even poor PMs would excel at.  Unfortunately, some PMs treat knowledge & information like power – sharing it with those they wish to curry favor with, and leaving everyone else in the dark.  Other PMs have a case of verbal “Montezuma’s revenge” – this is equally bad as stakeholders are unsure what information is critical and what is minutiae.  I covered this issue more extensively in the article “A dripping faucet or a fire hose – which most resembles YOUR project communication strategy?”

2. Neglecting stakeholders – As I wrote in “Don’t get blindsided by stakeholder influence” , PMs can get tunnel-vision by focusing purely on their direct customer or sponsor.  While this individual might be the one signing deliverable acceptance forms and evaluating your performance, a good PM needs to practice 360 degree management – sponsor, stakeholders & team. 

 3. Inaccurate or incomplete project control books – It doesn’t matter how heavy or light your PM methodology is (or even if you organization doesn’t have one).  There’s a basic set of project data that should be kept current so to facilitate project tracking, control, monitoring and (if you win the lottery) transition.  Having an out-of-date schedule is worse than having no schedule at all – at least a stakeholder doesn’t draw any wrong conclusions from a non-existent schedule.

 4. Ignoring conflict – Conflict is a natural occurrence on most projects but accidental PMs are often unused to managing interpersonal conflicts and might be tempted to ignore them in the hopes that the situation will resolve itself.

 5. Jettisoning risk management – If a PM happens to be aware of good project management risk practices, they might not have the intestinal fortitude to “sell” the necessity for these practices to their sponsor, stakeholders or team.  Under pressure to deliver, if they skip risk management, they’ll at least have the opportunity to improve their fire-fighting skills!

 6. A blind focus on the triple constraint – While scope, schedule & cost constraints are important, a PM might ignore the fact that a project has to deliver business value to avoid “the operation was a success, but the patient died” syndrome.  Poor PMs are less likely to ask questions such as “Is this deliverable necessary to the end result”, “Are we gold-plating” or “Is this project still of value to the organization”?

 7. Poor assumptions management – Projects possess uncertainty and to try to reduce this uncertainty, we make assumptions.  A good PM will log critical assumptions, share them with the overall project team, attempt to validate them proactively, and use them as one of the inputs into risk identification.  A bad PM will forget the assumptions shortly after they were made…

By no means is this list exhaustive, so I’d encourage you to contribute some of your own in comments.  Hopefully, we can distill a comprehensive set of cardinal sins to eliminate that justification for bad PMs: “I didn’t know!” 

Don’t forget to leave your comments below.

Learning using analogy is a common approach used when gaining knowledge, and as most project managers will likely have seen at least a few episodes of the original Star Trek series, here are some PM lessons to be learned from the valiant crew of the Starship Enterprise (beyond knowing when not to wear a red shirt!). 

1. Infinite Diversity in Infinite Combinations (IDIC). This tenet of Vulcan philosophy supports the rationale for cross-functional teams.  The diversity of the Enterprise’s crew contributed both varied experiences and versatility to their shared purpose and demonstrated that the whole can be more than just the sum of the parts.  Project managers sometimes complain about the challenges of building teams with resources that come from different backgrounds and departments, but it is this variety that can help overcome the toughest project issues or come up with truly innovative solutions.
2. Leverage the Specialized Skills of Your Team Members (and don’t get in their way!)  While Captain Kirk might have had a general understanding of most disciplines, he still knew when to defer to the advanced scientific, engineering, medical, communication or navigation skills of his direct reports.  Project managers, especially those that have played an SME role in the past, have the tendency to roll their sleeves up.  This is a good thing, but they should ensure that they are not neglecting their primary commitments or stepping on the toes of the team members that are responsible for those areas.
3. Hold Yourself and Others Accountable for Responsibilities and Commitments Although Kirk was a people person, he had no difficulty in throwing direct reports in the brig if they deserved it, removing himself if he felt he was not fit to command, or challenging authority figures if he felt that they were not “doing the right thing”.  Turning a blind eye to people issues might avoid conflict in the short term, but will undermine team morale or productivity and can eventually fester into a much bigger problem.
4. Follow Process but Don’t be a Slave to it.  The crew of the Enterprise embraced the policies and procedures established by the Federation, but also broke these rules if the situation necessitated it, so long as their actions were in line with the overall mission or vision of the Federation.  Project management methodologies and policies are tools to be used consistently, but they need flexibility to allow project teams to make their own decisions under special circumstances.
5. Communicate Bad News Effectively in a Timely Fashion. When the situation took a turn for the worse, Kirk would get on the PA and let the crew know what was going on.  Project leaders sometimes follow the “ignorance is bliss” approach, but a lack of consistent, open communication is a common cause of team morale issues and project failures.  It is important to present bad news in a solution-focused format – Kirk refused to believe in the “No Win” scenario, and that optimism is something else that project managers could adopt!

 Follow these lessons from Star Trek, and your PM career may “Live Long & Prosper”!

Don’t forget to leave your comments below. 

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. (http://www.solutionq.com) which produces and implements project portfolio management (PPM) solutions. Kiron has worked for over twelve years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries. Kiron served as a volunteer director on the Board of the Lakeshore Chapter of the Project Management Institute (PMI) for six years and remains an active member of PMI. Kiron has published articles on PPM and project management in multiple industry journals and has delivered presentations within the PPM/PM domain at multiple conferences and through regular webinars for Solution Q and the PMI Healthcare SIG. For more of Kiron’s views on change management, please visit www.eclipseppm.com or contact him directly at kbondale @ solutionq.com.

If you have been involved with project management for any length of time, you likely have been asked to explain or justify the value of project management.  The challenge in answering this question is that while it is fairly easy to provide a comprehensive response, you may not feel that confident if you are put on the spot to answer this question in a stereotypical “elevator pitch” of thirty words (or seconds) or less! 

A reasonable assumption is that the answer will be role-specific based on who is asking the question so let’s evaluate this from the perspective of key stakeholders.

Project sponsors provide financial and influence funding and support for projects.  In this capacity, they act in a similar fashion to investment managers in a brokerage. To be successful, they need their investments to provide guaranteed returns.  While a project manager cannot be held solely responsible for the successful realization of the benefits of a project, application of project management practices can reduce the surprises and increase the likelihood of projects being completed within established constraints.  This in turn helps to reduce uncertainty for the sponsors so that they can focus on ensuring that the benefits of the project are achieved.

For resource managers, gaining better visibility into the demands on their staff while simultaneously reducing resource contention is a key benefit.  Without knowing when resources are needed, for how long, and with what skills, as well as knowing when changes occur on projects that can affect these commitments, it is very difficult for them to do their jobs as resource providers or to motivate their staff.  Project management can extend the knowledge of planned resource allocations and can improve visibility into those factors that could affect the planned allocation.

For senior executives, projects are a means to an end. They help to deliver the strategic plan for the organization as well as supporting other objectives, including regulatory compliance and maximizing shareholder value.  In the absence of project management practices, the likelihood of success for large initiatives rests solely on the skills, motivation and dedication of staff. This is certainly a critical success factor for any project, but insufficient to assure executives that long running projects will complete on time and on budget, while providing the expected “bang for the buck”.

Finally, let’s consider project resources. They might perceive project management as an administrative burden.  However, with appropriate project management skills being applied to their projects, they should have a better understanding of their short and long term task lists as well as how the work they are doing will benefit the organization.  The issues they encounter on their projects will hopefully be escalated and resolved in a timely fashion, and the expectations for how they perform their work, as well as the performance evaluations they receive, should not be unexpected.

While each role may experience slightly different benefits from the use of project management, a commonality to all of these value propositions is improved predictability.  The advantage of using this simple statement is that the focus of the predictability is in the eye of the beholder. For a sponsor, it is about having their project completed when they expected at a price point they had justified. For a project resource, it could be knowing what they will work on this week and feeling confident that hurdles they encounter will be appropriately escalated and addressed.

So the next time someone puts you on the spot to “sell” project management, counter with “improved predictability.” Of course, when those elevator doors open, you might be invited to deliver a more comprehensive explanation!

Project Portfolio Management (PPM) has been around for at least thirty years and over the last decade there has been a proliferation of standards, publications, and conferences on the practice.  While a significant amount of emphasis has been placed in these knowledge sources on understanding PPM critical success factors, good practices and processes, the same plethora of documentation is not available about assessing the benefits achieved by adopting PPM practices.

Don’t get me wrong. In product development organizations, there is a direct linkage between good PPM practices and improvements in overall return on project portfolio investments.  But what happens if your company does not develop products or services?  Even worse, what happens if you have decided to take a phased deployment to PPM practices by rolling them out within a single department instead of doing an enterprise-wide approach?

If you are a year or two into your PPM initiative and senior management is beginning to ask tough questions about value realized, what can you do?  You could spend time interviewing stakeholders to gauge perceptions of PPM capability and benefits but these will be subjective and intangible – valuable to document, but not helpful towards developing a cost justification.

In the absence of a good baseline of past history, you could focus on quantifying the benefits of specific instances in which the application of PPM practices made a difference.  If a project request that might have been launched historically was rejected by your governance committee, try to quantify the impact and costs if that project had been launched.  If a project  that in the past might have been allowed to continue through to completion, was terminated “in flight” to continue through to completion, assess the opportunity costs. Which other projects might NOT have been resourced?  If information about a project that resulted in the “right” decision being made in a timely fashion had not been available at that time, what could the costs have been?  On the cost side, assess the organization costs of PPM – staffing costs, training and coaching costs, and tool implementation and support costs.

As you can see, this type of retrospective value justification can be challenging and effort-intensive, so how can you proactively avoid this dilemma?

1. Identify key organization performance indicators (financial or otherwise) that the PPM initiative will improve.
2. Capture a baseline of data about these indicators over a quarter or two.
3. Develop realistic, achievable targets for changes to these indicators.
4. Develop a business case based on these improvements taking into account the hard and soft costs of the PPM initiative.
5. Secure appropriate executive sponsorship to provide you with both the funding and visibility for the project.
6. As PPM changes are rolled out, measure these indicators on a regular basis (as well as the costs of the initiative) and provide annual (or better yet, quarterly) updates to senior management regarding the benefits achieved.

Quantifying the value of PPM is a true example of the saying “if you fail to plan, you’ll plan to fail!”.

A systemic lack of predictability regarding resource availability threatens to trump unmanaged scope creep, technical complexity and organization change resistance as the primary source of project risks.  Achieving an organization’s strategic objectives gets impacted as transformational projects require specialized skills that are in high demand and in low supply – this was admirably depicted by Scott Adams in a recent Dilbert cartoon (http://www.dilbert.com/strips/comic/2010-06-21/). 

The obvious solution to this is to either add more resources or take on less work in parallel. The first choice is usually unrealistic and success with the second is not achieved overnight.  Reducing the volume of multitasking is a key to more predictable throughput, but convincing senior management that you can actually do more by doing less is not easy. 

 In the interim, here are a few tactical steps that a project manager can take:

1. Pity the poor resource manager who has competing demands on his/her resources’ time!  Unless your organization follows an objective project prioritization approach, priorities are likely set by whoever screams loudest.  In this situation, your best chance of improving resource availability predictability is to have a positive relationship with these resource managers so that they will try to be as considerate as possible with your resource needs.  If you are really lucky, they may even be motivated to assess and modify the resources’ operational duties to help you out.
2. Reduce the degree of project internal multitasking – it’s bad enough that your team members are likely working on other projects as well as operational activities, but at least try to avoid their having to context switch between tasks on your project! 
3. Multitasking creates inefficiency as a result of context switching. Reduce the effort wasted in context switching by simplifying the ramp up/ramp down for team members.  One way to do this is to decompose work activities to a low enough level of detail, so individual tasks can be accomplished within one or two context switching cycles at most.
4. If your organization does not have a standard PM methodology, work with your peer project managers to define a consistent set of expectations for team member progress and issue management.  If a resource knows that the reporting requirements are consistent across the concurrent projects they are assigned to, that’s one less thing for them to worry about learning (and re-learning!).
5. Walk a mile in their shoes. When team members have multiple projects and operational activities to complete, increase the likelihood that they will want to work on yours by ensuring they understand how their tasks (and the success of the project as a whole) will benefit the organization and them.  Remove as many barriers to their being able to efficiently complete their tasks as possible. That means no unnecessary meetings and be sure to streamline project administration and communications as much as possible!  Take a page from agile approaches and embrace the role of a project manager as being responsible for clearing the hurdles from the team’s path.

Resource availability unpredictability is here to stay. You can make like an ostrich, stick your head in the sand and hope the problem goes away. Or you can take some tactical steps to increase the odds of success for your project, while simultaneously evangelizing the merits of reduced multitasking!

Which is it to be?

There is a strong likelihood that if you have taken a project management training course within the last decade you have heard some variant on the saying that “90% of a project manager’s time is spent communicating.”  As with everything else, too much of a good thing can cause problems.

I have worked with junior project managers (as well as some seasoned ones) who focus on over communication instead of effective communication.  Their concern is that the perceived importance of information is in the eye of the stakeholder. They are concerned that, if the project manager does not provide “full disclosure” to stakeholders, sponsors or team members, the project manager’s information filtering could spawn or worsen a project issue.

This is a valid risk – a lack of open communication of assumptions, issues or risks has likely caused more project failures than scope creep or limited resource availability. 

However, to swing the pendulum from limited communication to the other extreme raises some risks.  For a sponsor or stakeholder to find some data that is of value to them, they have to wade through reams of interesting but low value (to them) information.  Additionally, drowning stakeholders in minutiae is a good way to lose their interest or attention in your project, to say nothing about reducing credibility in the project manager’s capabilities. 

While useful for sharing project information or eliciting feedback, online communication methods such as Twitter, Instant Messaging, and worst of all, e-mail can dramatically aggravate this situation.  While this information overload issue is dangerous for traditional projects, it is lethal for virtual projects as it increases the probability of stakeholder isolation or withdrawal.

So how does one determine the sweet spot for project communications?  

1. Include a thorough stakeholder analysis as part of your project communications planning.  For key stakeholders as well as your sponsor, make sure you understand what, when & how do they wish to be get apprised about.
2. Leverage both push & pull methods of communicating – push information that is time sensitive or requires action.  Let other information be pulled by stakeholders (unless they have specifically asked you to push it to them).
3. Refresh your communications plan based on feedback.  Meet with stakeholders on a periodic basis to gauge if they feel that your level of communication is effective.
4. Be consistent in communication content & structure.  This helps to reduce effort spent by team members or stakeholders in processing information and demonstrates predictability and professionalism.

You have likely experienced this at least once in your project management career – your team has thoroughly planned a complex project and has decided to add contingency reserves to hedge against “known unknowns.”  Even in the halcyon days preceding the current global financial crisis, it was common practice for sponsors or other governance bodies to challenge or strip out such perceived buffers.

While not the only cause, one of the primary contributors towards this rejection of contingency reserves is the subjective approach used for their definition.  Risk perception is susceptible to bias – customers tend to be optimistic about expected project outcomes so it can be challenging to convince them of project risk severity.  The more a team can do to quantify the level of risk on a project and to educate sponsors or customers on the use of contingency reserves, the greater the likelihood that decision makers will support the need for these reserves.

Quantification begins with SMART (see http://en.wikipedia.org/wiki/SMART_criteria ) risk identification to improve credibility in project risk management practices (see http://www.projecttimes.com/kiron-bondale/capturing-the-hearts-and-minds-of-project-risk-stakeholders.html for more insights on engaging stakeholders through risk management).  If your project sponsor or customer is involved in the risk identification process, he or she should already be aware of the specific risks that requested reserves will cover.

Once the risk register has been populated, project teams can use techniques such as the Delphi method to come up with reasonable estimates for probability and impact of occurrence (even if historical data is not available).  Probabilities of occurrence can be estimated as low (25%), medium (50%) or high (75%).  Estimated impacts should not assume the worst case scenario as that will negatively impact credibility in the evaluation.  Once this evaluation is done, expected impact values for risk events can be calculated by multiplying the probability percentages by the estimated impacts.  By summing the expected impacts for all schedule-impacting risks and all cost-impacting risks your project team will have a “maximum” value for contingency reserves.  Obviously you should not present these figures, but you are in a better position to justify the rationale for suggesting that a reasonable percentage of these be allocated as reserves.

Beyond risk quantification, it is important that sponsors understand how contingency reserves are used – a common misconception is that these are “slush funds” that will be misused by project teams.  Educating them on (and following!) a consistent process for the use of contingency reserves (e.g. critical chain project schedule buffers) can help to ease these concerns.

 In spite of these recommendations, you might still encounter the occasional holdout who rejects your request for contingency reserves.  In these cases you consider stating (as diplomatically as possible!): “I understand that you do not feel that contingency reserves are necessary for this project.  As such, would you be willing to sign a decision record reflecting that you are guaranteeing that none of these risks will be realized?”

In the course of assessing project management capabilities for clients, a practice that I’ve found absent across most non-projectized organizations is the evaluation of team members at the end of a project by the project’s leadership.  Usually, the rationale provided for this gap is that the functional managers do not consistently solicit this feedback from project managers, or when this feedback has been offered in the past, it has been ignored. 

 If you are struggling with “selling” this practice internally, consider using one or both of the following issues as the catalyst for introducing this change:

• With the exception of purely operational staff, most resources spend a reasonable percentage of their time working on projects.  When evaluations are conducted annually, functional managers lack objective criteria to assess performance on project work and must either resort to generalizing performance based on a resource’s operational performance, or will use anecdotal feedback received from the most recent projects.  This impacts the consistency and objectivity of the evaluation process.
• A common belief is that staff will focus on activities that will directly impact their evaluations.  In a matrix model organization, if post-project feedback is not provided, team members may prioritize their operational work higher than their project work.  This may not be a conscious decision, it might simply be conditioning over time – a functional manager is a constant for the resource, whereas a PM is a transient authority (at best).  This increases the likelihood of overworked or heavily multi-tasked resources procrastinating or delaying the completion of their project tasks.

To increase the likelihood of consistency in the evaluation process, the following practices should be incorporated:

1. Use an objective evaluation scorecard with a few (five or less) questions that either have a Yes/No answer, or a numerical answer (e.g. on a scale from 1-5, how would you rate…).  Provide room for comments, but ensure that the majority of the feedback is solicited objectively.
2. Insist that PMs establish expectations about the evaluation process with their team members as part of the project orientation process – it does no good to have someone evaluated at the end of a project if they don’t understand the basis for this evaluation.
3. Structure annual evaluations to include the aggregate scores from projects as a component of the overall score – the specific percentage will vary based on the amount of time that a given role spends performing project work.

 Even if your organization follows a functional (i.e. not matrixed or projectized) model, these practices can still apply.  While your functional managers might be leading the majority of the projects that their direct reports work on, conducting consistent objective evaluations at the end of each project can vastly simplify the work effort for managers during annual evaluation time.

Without balanced resource performance evaluations across operational and project performance, similar to lessons learned (see http://www.projecttimes.com/kiron-bondale/lessons-learned-avoid-the-oxymoron.html), those who cannot remember the past are condemned to repeat it!

Don’t forget to leave your comments below

It’s the classic Catch-22. If your organization does not spend sufficient time evaluating requests before projects are formally authorized or executed, predictability of project outcomes decreases. 

On the other hand, time spent in evaluating requests (especially for those that will never be approved) is often perceived as an opportunity cost. The skills needed to perform the evaluation are likely the same skills needed to staff key projects.

No one contends that we should not expend effort in evaluating project requests prior to their approval.  Even organizations that only use the “squeaky wheel gets the grease” process for project selection and prioritization will usually expend a minimum amount of effort to ensure that truly insane concepts don’t get furthered. 

The dilemma is to know whether the effort being spent results in a cost justifiable improvement in project predictability.  This is where measurement and agile techniques can help.

Measurement begins with capturing effort spent on project request analysis and evaluation activities separately from other time reporting “buckets”.  This is not a normal non-project activity category in most organization’s time reporting systems, and there should be clear guidelines on its usage. Ideally, it should be used to capture any effort spent on project request analysis from the point of initial submission tol the point of official approval (at which time further effort spent against the project would be considered part of the cost of that project).  This effort should be reported to governance bodies at quarterly or semi-annual intervals and can help to tune your work intake processes.

Checklists or other such tools can improve the efficiency of processing requests and can improve the consistency of the assessment projects.  For certain types of projects, commercial estimation tools can accelerate the process of coming up with ballpark costs using either parametric or analogous estimation methods.

However, agile principles can best guide us to avoid wasting unnecessary effort on detailed planning, especially when there is a significant potential for requirements or scope flux. 

Project requests should be able to demonstrate the delivery of business value in a phased or iterative approach as opposed to the traditional “big bang”.  This can reduce the organization’s sunk cost in low value projects and will help to increase the realism or accuracy of business cases. 

Assuming a phased value delivery approach, request evaluation can focus on the first couple of iterations. If a project does not merit funding based on those, there is a high likelihood that it would not benefit the organization after its final iteration.  This sounds like classic “short term” thinking, but it avoids “Holy Grail” quests that consume tremendous resources but return very little when they are finally over.

Analysis of project requests to support “go/no-go” decisions is not free, but through regular effort measurement and by the appropriate application of agile principles, the value achieved through better project selection and prioritization can justify its costs.

Don’t forget to leave your comments below

So what are some of the other benefits of an accurate project schedule beyond its primary value as a work management and tracking aid?

1. It is a powerful communication tool – whether you are presenting project status updates to senior management, your customer, or reviewing upcoming work with team members, an accurate project schedule provides an objective method of communicating schedule progress, as well as highlighting the potential impacts of project issues.
2. It is a wonderful medium for knowledge capture – a critical weakness in most organizations is the inability to effectively capture and leverage expert knowledge. A well developed, accurate project schedule can cut down on the ramp up time for new staff and can incorporate lessons such that they are more readily learned.
3. It facilitates compliance with organization policies and procedures – embedding critical steps from operational or quality checklists into a project schedule increases the likelihood that they will be followed. If a checklist or standard operating procedure is documented, filed in a binder and referenced only during initial staff training, it becomes easy to forget. On the other hand, if the key steps within the procedure or checklist are built into a project schedule, not only is it hard to miss by team members, compliance issues become much more visible.
4. It is a fundamental input into risk identification at all stages of the project lifecycle – while a risk register should be developed early in the lifetime of a project, it loses value if it is not reviewed and refreshed at regular intervals. An accurate project schedule can provide an efficient basis for ensuring that all remaining activities are considered from a risk perspective.
5. It can reduce the effort required to analyze change impacts – without an accurate schedule it is difficult to assess the schedule, resource and cost ramifications of a significant project change. Not only can a schedule improve the quality of impact analysis, it also provides a means of simulating the impacts of different approaches to a proposed change.
6. It facilitates project and portfolio-wide resource planning – human resource availability is one of the top constraints and ongoing sources of risk to projects.The ability to forward plan resource allocation through use of detailed, accurate project schedules is crucial to being able to proactively identify and avoid resource bottlenecks.

In summary, a project schedule is merely a model and like any model, it can only bring order and predictability to chaos if it is accurate. While you should avoid the temptation of spending too much effort in the development and ongoing maintenance of the “perfect” project schedule, striking the right balance between accuracy and effort will reap multiple rewards, beyond just knowing that you are “on track”.

Don’t forget to leave your comments below