Projects get started for a variety of reasons but good intentions are usually not enough to justify investment. In spite of defining or enforcing intake criteria, projects continue to be launched which should never have left the dry dock.
What are some of the warning signs to look out for?
No one appears to be able to answer the question Why?
I’m not asking for a detailed scope definition or “to be” process map. All I am looking for is someone who is able to paint the picture as to how the world will be better if this project gets completed. Without this, the likelihood of significant effort being invested in a snipe hunt increases.
Sometimes the initial answer to why we are doing a project is superficial – in such cases, you could use 5 Whys to try to identify the real reason. If it turns out that it’s just to build someone’s empire or stroke someone’s ego, back away slowly…
Too many throats to choke
While it might take a whole village to raise a (project) child, diffused accountability translates to weak governance which results in ineffective decision making. If there isn’t a clear understanding before the project starts as to where the buck stops, keep looking.
Too many external dependencies
Every dependency can be a source of risk. The more a project will rely on all the stars aligning perfectly, the less likely it is to succeed. If there isn’t an easy way to reduce the number of external dependencies, is it still worth proceeding?
There’s too much going on
If the sponsor, key stakeholders or core team members are distracted with multiple other bright, shiny objects, how much are they likely to focus on your project, and what will be the quality of the decisions and deliverables produced? Unless you are confident that this project can bubble up to the top of their priorities (and stay there), maybe it’s better to wait until they can focus.
It doesn’t align with the company’s risk appetite
Organizational risk appetites can evolve, but that shouldn’t be because someone has decided to bet the farm on a “sure thing”. Too big to fail just means we haven’t been hit by a big enough asteroid yet!
There’s no risk in delay
Is it important but not urgent? What’s the worst that could happen to the company if the project was delayed by a year? If there isn’t a compelling reason to launch the project now, there might be some other more urgent initiatives which could use the resources.
Have we tried (and failed) before?
Sometimes organizations learn from past stumbles and are able to succeed on future attempts – those are the exception, not the rule. Without fundamental changes in underlying conditions, capabilities and expectations, there’s a strong likelihood of repeat failure.
If your project breaks one or more of these rules, how confident are you that you will avoid realizing the risks posed?
(Note: this article was originally written and published by me in March 2016 on my personal blog, kbondale.wordpress.com)
It is a commonly held belief that in the absence of a higher driving need, people will focus on those activities or behaviors for which they are being measured and subsequently either positively or negatively reinforced.
Given this premise, it should be no great revelation to leadership teams that if a balanced approach is taken by governance bodies to project oversight, this should result in a correspondingly greater incentive for project teams to consistently perform practices across all key project management knowledge areas.
This is why it never ceases to amaze me that the same senior stakeholders who complain about the lack of practice consistency across their project teams with regards to certain knowledge areas are equally guilty of forcing these same teams to focus on one or two specific constraints.
Please note that I’m not referring to the practice of communicating the priority of project constraints as it relates to the business objectives or key drivers for a project. That is an essential activity which will ensure that project and governance teams make the right types of trade-off decisions. For example, if a particular project is addressing a time-sensitive regulatory requirement, schedule is the primary driver and it is perfectly reasonable for the project team to propose decision recommendations which will protect project deadlines at the cost of other constraints such as scope or cost.
However, should an organization focus exclusively on one or two constraints across all projects in the portfolio, this can result in a culture which colors not only team decision making, but also the degree to which they comply with the company’s project management methodology. While you might feel that a safety measure to guard against this outcome is regular project assurance reviews or audits, non-compliance findings which are unrelated to the supreme constraint are likely to be marginalized.
A common example of this behavior occurs in companies which are under sustained financial pressure or scrutiny. The last decade has not been kind to both public and private sectors, hence it is little surprise that cost is king. You might feel that regulatory projects or product development projects would give time a higher priority, but even on those, it is rare to see governance oversight bestowing financial carte blanche on teams just to hit a date. Budgeting, financial tracking and reporting are usually performed quite diligently as there is significant oversight in that area, but the same is usually not observed across the remaining knowledge areas.
While you might feel that this neglect may apply to practices such as risk or quality management, it might even be identified on the stereotypical project management practices of time or scope management. This is certainly not to say that teams are ignoring milestone delivery dates or customer requirements. Results are still being produced but they might not be delivered following consistent practices.
If you are still skeptical, do a spot check on your own project portfolio:
If you have identified that there does seem to be an unhealthy focus on one constraint, you will likely want to review the implications of this with your senior management team. If nothing else this gives you the opportunity to conduct a leadership gut check to help you determine whether there is real commitment to establish or improve organizational project management capability.
This might also provide you with a good coaching moment to debunk the myopic view that one can safely neglect certain project management practices without causing an impact to the chosen ones – as we all know, there is a very tight dependency between all knowledge areas.
W. Edwards Deming is often erroneously quoted as having said, "You can't manage what you can't measure." In fact, he stated that a cardinal sin was trying to run a company based solely on reported measurements. The same could be said of an excessive organizational focus on one constraint.
(Note: this article was originally written and published by me in December 2013 on Projecttimes.com)
One of the symptoms of lower organizational project management maturity is having more projects active than can predictably be delivered by teams. Even if processes have been implemented for work intake or prioritization, if governance committees continue to accept all project requests presented to them (i.e. the project funnel is a tunnel) the likelihood of staff overworking but still under delivering is high.
In most cases, this may not be the worst thing that could happen – so long as project and functional managers are able to keep their team members focusing on completing the most critical milestones, delays on less important projects might be an acceptable inefficiency.
Where this does become more concerning is when there are multiple genuinely important projects underway and this gets coupled with a work allocation model that has most staff performing operational and project duties. In such cases, there is a strong probability that at one or more times of the year, there will be a convergence of “can’t miss” milestones across multiple projects conflicting with the completion of one or more critical operational initiatives.
In an organization with lower levels of maturity, this situation can be similar to the chaos that would ensue if a half-dozen footballs were dropped in the midst of an unsupervised group of preschoolers. In the organizational context, staff will focus on the project milestone or operational activity which has been given the greatest priority by their project manager (in strong or some balanced matrix organizations) or by their direct reporting manager (in functional, weak or some balanced matrix organizations). Since not each team member will receive the same instructions or priority directions, the risk is high that nearly all milestones will be missed.
To avoid such entropy, the easy answer is for the organization to take on less work – they should cut their coat according to their cloth. However, this requires a fairly detailed quantitative understanding of staff capacity and capability as well as a governance team that is judicious about project selection & scheduling – both signs of a higher maturity organization.
Failing this, what else can be done? Try to avoid milestone convergence at all costs.
While the ultimate tool to help achieve this might be a detailed cross-project/operations schedule, this will take a tremendous amount of effort to develop and, in low maturity organizations, it will be out-of-date the moment it has been published.
A simpler approach is for project & functional managers to maintain a list of critical milestones for their project and operational responsibilities for the next few quarters. The only information required to be captured is the name of the initiative, the milestone description, the true degree of schedule flexibility for the milestone (or rather, the impact if the forecast date slips) and the forecast date.
When developing project schedules or creating operational calendars, project and functional managers should review this list and if they are in a situation where a new milestone will conflict with existing ones, a quick meeting should be called to identify the “pecking order” at the milestone (NOT project or initiative) level, and rescheduling should take place on all other initiatives. If this can’t be done for a particular convergence point, at least the organization will have a sufficiently advanced “head’s up” to assign additional staff or other such techniques of avoiding contention.
Reducing the number of active project and operational responsibilities for staff is a long term goal for lower maturity organizations, but a good short term objective is to shift focus to key milestones across concurrent work streams to avoid perfect storms.
(Note: this article was originally written and published by me in June 2013 on my personal blog, kbondale.wordpress.com)
A common question that arises during project initiation is what is the optimal percentage allocation of a project manager to the project to ensure the right balance between cost and risk. This question should be distinguished from the determination of how much project management effort in total is required since multiple staff will participate in project management activities over a project's lifetime.
In a billable project, this question often generates significant lively discussion – depending on the customer’s project management maturity level and the desire of the sales team to win the business, it can sometimes be a tough sell to ensure there is sufficient allocation of effort and funding for the project manager. However, even in cases where the project effort is not being charged to someone, it is possible that there may be preconceived notions regarding what is a reasonable allocation of time.
Most of you will know that the only right answer for most project management scenario questions is “it depends” and this is no exception. Although there is no single formula to help you calculate how much of a project manager is needed as this can vary from as low as 5% to full-time allocation, it may be helpful to understand the factors which could affect involvement.
While this list might not eliminate disagreements regarding the appropriate allocation of a project manager to a given project, it should help to make those discussions more objective.
Are there any factors which I have missed or can you come up with a formula that combines these to provide a good rule of thumb – if so, please provide your comments below!
(Note: this article was originally written and published by me in May 2013 on Projecttimes.com)
So you want to buy a PPM or EPM (Enterprise Project Management) tool?
Congratulations – vendors will be filling up your e-mail Inbox with ROI calculators, dazzling dashboard screenshots and glowing client case studies to convince you that their solution is the only reasonable choice!
But before you finalize the business case to secure funding, let’s run through a simple list of questions. If you can’t conclusively answer “yes” to all of them and have the data to back up this confidence, it might be advisable to wait until you do.
Are your PM practices institutionalized (and how do you know)?
If you don’t have some sort of documented methodology, and don’t have the evidence reflecting compliance with those practices, why do you think introducing a tool is going to make any difference?
Do you have sustainable executive sponsorship AND resource management commitment (and how do you know)?
If you have been trying to sell these two stakeholder groups on the benefits of introducing a tool, how do you know they have sufficiently bought in? Everyone wants to have pretty portfolio health dashboards and detailed views into staff capacity and allocation, but a lot of effort on the part of mid- and senior managers is required to ensure that accurate and complete data is being entered by project teams.
Who is going to support the tool past the initial roll out (and will you have sufficient funding for these resources)?
Regardless of whether a PPM or EPM solution is installed on-site or subscribed to over the Internet, you still need to have internal staffing to provide application support to your end users, to identify and address coaching or compliance issues, and to receive feedback from end users and incorporate that feedback into ongoing improvements to your procedures & the configuration of the tool.
Beyond this, depending on your organization’s needs and the capabilities of your selected tool you may require software development assistance for creating interfaces with your other business systems and report writers to create custom reports from the tool’s centralized repository.
Will the costs of providing this support be absorbed by the tangible benefits achieved by implementing a tool? If not, how will you justify ongoing funding for it?
How are you going to “sell it” to the primary end users?
Vendors tend to target executives when selling PPM and EPM tools as dashboards and reports make for great eye candy, but to populate those dashboards and reports the burden of effort falls on project managers & team members as they are expected to enter and maintain project data.
Will you be reducing or at least not increasing the administrative work load for these folks?
Don’t get me wrong – PPM and EPM tools can provide significant benefits, but without checking that the prerequisites for successful realization of these benefits are in place you might find that all you’ve done is acquired a costly Rube Goldberg project administration machine.
(Note: this article was originally written and published by me in September 2013 on my personal blog - https://kbondale.wordpress.com)