Managing to the triple constraint is table stakes – it’s past time for project managers to go further.
The natural concern which might be raised is that in many cases a project manager has moved on to their next project while the product owner and other stakeholders are still working on the change sustainment required to achieve benefits. The project manager might have had limited direct involvement with the staff who are required to successfully adopt the changes, or might have no influence over the external factors which could impact benefits realization.
This is all true, and yet, if the project fails to deliver the benefits promised, the project manager is likely to receive some of the blame.
This is not to say that project managers don’t attempt to lay the groundwork for success after they have closed out their projects. Sometimes, the fault might lie with protective product owners who may perceive such efforts by the project manager as crossing jurisdictional boundaries. However, this is no reason for a project manager to back off. If they have sufficient evidence to show that benefits realization will be impacted, it is their responsibility to ensure that this information is acted upon.
During the project’s initiation, the project manager should take the time to understand the business case supporting the sponsor’s rationale for investing in the project. This is one of the benefits of a project manager having domain expertise. A project manager who has only a cursory understanding of the impacted business processes may be less likely to understand if some fundamental assumptions are invalid or might miss threats which would impact successful benefits realization.
While a business analyst is usually responsible for requirements elicitation and should be ensuring that the requirements gathered directly tie back to the original business case and expected benefits, the project manager should also take the time to thoroughly review the requirements baseline as that acts as a key input into many downstream decisions which may impact project success. By doing this the project manager is better equipped to support the business analyst in facilitating appropriate decision- making when scope changes are brought forward later in the project’s life.
For projects which are expected to deliver financial benefits, the project manager should not only focus on the definition of the project’s one-time costs, but should also review the incremental ongoing costs and expected revenue projections estimated by the product owner and other stakeholders. If the assumptions underlying those estimates don’t appear to be valid or if the project manager believes that a key constraint might have been missed, they should not hold back on sharing their concerns.
Once work has begun on delivering the project’s approved scope, most project managers tend to focus their efforts on keeping project delivery on track and effective managing changes to baselines. To complement the normal project delivery assurance activities, the project manager should consider taking the time to revisit the business case periodically to identify changes which may impact benefits realization.
The project manager can help to facilitate benefits reviews with the product owner by identifying and engaging the right stakeholders who can provide input into the assessment process. If the project manager and product owner determine that there has been a significant reduction in anticipated benefits, this should trigger a review with the appropriate governance body to decide whether the project should continue to be funded to avoid incurring further sunk costs.
Scope changes provide another opportunity for project managers to go beyond their traditional project delivery role. While understanding the impacts to scope, schedule, cost, and secondary project constraints are important, impacts to benefits realization should also be identified to avoid unintended consequences.
Successful change adoption and sustainment is another critical input into benefits realization. The best project deliverables will generate minimal value if operational staff don’t modify their behaviors to take full advantage of the changes. Through regular stakeholder interaction, the project manager is in an ideal position to receive feedback from groups impacted by the change. The project manager can support change owners in stakeholder analysis and action planning and can ensure that priority is placed on securing the necessary change agents from each impacted area. They can review change plans and help to facilitate the risk identification and assessment sessions required to understand what threats may exist to successful adoption.
I am not discounting the effort and challenges required to bring in a project within approved scope, cost and schedule baselines, but that just isn’t enough these days. Like it or not, you will likely be assessed not just on project delivery, but also on whether your projects have achieved their expected benefits.
(Note: this article was originally written and published by me in June 2015 on Projecttimes.com)
What are the most impactful ways to learn about project management?
We tend to think of the experience (and scars) we’ve gained through managing multiple projects, the formal education we’ve taken and the certifications we have achieved.
No doubt, these are all contributors to our current competency, but we are underestimating how much valuable project management advice we received from our grandparents through old proverbs.
Here are just a few examples of what we’ve unconsciously learned about project management from previous generations.
A stitch in time saves nine – yes, that lingering low priority issue could probably go another week without being followed up on, but wouldn’t you rather be safe than sorry?
Look after the pennies and the pounds will look after themselves – it does pay to review actual time logged by your team members even though that might seem administratively onerous!
Two wrongs don’t make a right – just because someone has used dirty politics to negatively impact your project doesn’t mean you should return the favor.
When in Rome, do as the Romans – there’s a good reason that “it depends” is usually the right answer when asked project management practice questions. How you manage a given project should never be solely dictated by enterprise methodology – it needs to take into account the context of the project, its constraints, and the team’s culture.
No man or woman is an island – too many project managers feel they are responsible for making all the decisions on a project – you have a team so leverage it effectively.
Hope for the best, but prepare for the worst – effective risk management is critical to managing uncertainty, but don’t forget that there are opportunities as well as threats to be managed.
A picture is worth a thousand words – sure, a detailed, thousand page business requirements specification might fully capture the customer’s needs, but a working prototype might be a more effective means of ensuring you deliver what the customer wanted!
You can’t make an omelet without breaking a few eggs – manage enough projects, and you’ll learn that you can either be nice or be effective, but it’s rare that a project manager can successfully be both all the time. Focus on being objective, fair and transparent, but recognize that you won’t be able to please everyone all of the time.
A watched pot never boils – micromanagement is bad, ’nuff said!
Too many cooks spoil the broth – the best argument I’ve heard for keeping team and meeting invitation list sizes small.
Don’t bite the hand that feeds you – I get it, you’ve got a weak or distracted sponsor. Just remember, they are funding your project, so it’s in your best interests to stay on their good side. Similarly, if you don’t like your people manager, don’t pull an end run around him or her – it’ll usually come back to bite you.
Don’t put all your eggs in one basket – by all means, develop a project plan at the right level of detail for your control needs, but also have a plan B in your back-pocket for if and when things go wrong.
I’ll close out with one of my personal favorites which PMI should consider adding to the Code of Ethics: Honesty is the best policy!
(Note: this article was originally written and published by me in September 2015 on my personal blog, kbondale.wordpress.com)
Agile transformations are susceptible to a variety of impediments but sometimes these hurdles are not as high as we believe them to be.
In almost any company other than a startup, some or all of the following tangible blockers will not only be present at the beginning of the journey, they may continue to stymie teams years into their transformation.
Are these likely to disappear quickly? Not likely. Some such as technical debt or legacy integrations can be eliminated over time with persistence and sustained investment but others are a natural by-product of a company's industry, the free market or globalization.
So when I hear teams complaining about these blockers during their daily stand-ups or in their retrospectives I recall Morpheus's exchange with Neo at the beginning of The Matrix.
Morpheus: To your left there is a window: open it... use the scaffold to get to the roof.
Neo's fears and doubts are more crippling than the lack of a dumpster below his office building which he could jump into or a fire escape ladder close at hand to get to the roof.
As the movie progresses, Neo continues to struggle with overcoming these constraints and Morpheus continues to coach him: You have to let it all go, Neo. Fear, doubt, and disbelief. Free your mind.
But Morpheus, like agile coaches, can only show the way.
Teams, like Neo must walk the path themselves. Once Neo understands the Matrix for what it is and embraces his place in it, his perception of limitations including agents evolves such that he no longer perceives them as great a threat as he and others make them out to be.
Once teams successfully adopt the right mindset, they can respect the impact of organizational blockers but continue to discover ways of being agile.
When house hunting, savvy shoppers quickly learn the meaning of some seemingly innocent phrases found in listing descriptions. For example, lots of potential means that you will have to spend a lot of money to make the house livable. Quaint implies that no upgrades have been made since the house was originally built.
When taking over a project from another project manager, similar rules apply. The customer, sponsor or departing project manager are all very motivated to get a competent replacement as quickly as possible. And while they wouldn’t blatantly mislead you, here are some telltale phrases to watch for while you are being wooed for the role.
We are a little over budget: The project has a cost variance which cannot be absorbed, metrics are likely not in place to quantify how big the problem is, and everyone involved is in denial.
We have a slick sponsor: That’s because he or she is made of Teflon with nothing sticking including escalated actions, risks, issues or decisions.
The team is very creative: I’ve just got two words for you – herding cats!
Stakeholders are very engaged: The only problem is that the majority of them are actively engaged in attempting to sabotage the project.
We’ve completed some deliverables: The team has produced a bunch of documentation.
There is a dynamic decision making process: Project governance processes were not well defined or practiced and decisions are being frequently challenged and reversed.
We are constantly learning: That’s because we are also constantly forgetting to apply the lessons we should have already learned.
This project will be a real feather in your cap: You’ll need the cap because you’ll likely tear all you hair out while managing it!
The project has been managed in an agile manner: Scope is constantly changing, nothing is documented, and everyone is doing whatever they feel like.
We have a project control book: Of course, no one looks and it because the content is very out-of-date.
You will need to roll your sleeves up: That’s because we have a significant resource shortfall.
While the purchase of a house might be the most significant personal investment many of us will make, leading a project represents an investment in our careers.
(Note: this article was originally written and published by me in May 2016 on my personal blog, kbondale.wordpress.com)
The perils of PMO proliferation
Some organizations struggle to improve their PM or project portfolio management capabilities without having a PMO. However, I’ve also encountered organizations that have established PMOs in multiple functional areas and at differing levels of authority – this situation is equally challenging.
Some of the risks of PMO proliferation are:
– Significant “hard” costs with limited perceived tangible benefits.
– A lack of process or tool consistency across PMOs results confuses PMs, resource managers, team members and other stakeholders and this in turn reduces the “bang for the buck” achieved from the overall organization project portfolio.
– Jurisdictional disputes between PMOs can impact credibility, cause communication issues and also reduce overall value received from a portfolio approach.
Large organizations may not be able to get away from having multiple PMOs, but a few ground rules can ensure that these risks are mitigated.
1. Ensure clear authority & mandate boundaries between the PMOs. For example, if there is an enterprise PMO and a departmental PMO, project portfolio management processes at the enterprise level should be controlled by the enterprise PMO where as project management practices within a department can be controlled by the departmental PMO.
2. Ensure consistent project metrics across all PMOs. The degree of discipline within each PMO’s methodology can vary, but the metrics that are reported for project status across different PMOs need to be consistent otherwise it is impossible to get an accurate understanding of overall portfolio health. Beyond the nature of the metrics, the frequency of gathering or calculating of the metrics also needs to be aligned so that executives know that project data is up-to-date across the board.
3. Ensure resource management data and practices are standardized across all PMOs. A critical foundation to project portfolio management is that organizations have to have a consistent, accurate, near real-time understanding of resource capacity and allocation. If one PMO is tracking resource data at the individual resource level while another does it at the skill level, it becomes very difficult to look at supply vs. demand at the organization level. Similar to the previous item, I recommend standardizing on a handful of resource metrics that are tracked in a consistent fashion across all PMOs. However, as resources can work on projects that span the oversight of multiple PMOs, it is important that resource request, allocation, evaluation and release practices are also standardized across these PMOs to avoid confusion and improve integration.
4. Use common tools across all PMOs. While the degree of project management discipline might change on a PMO-to-PMO basis, and some of the services provided by the PMO might vary (e.g. one PMO staffs the PMs for its projects while another only provides project oversight) the tools that are used to automate the PM processes should be the same. If not, significant cost and resource effort will be required for integration, establishing an organization-wide resource pool becomes very difficult, and it is much harder to negotiate for enterprise license or subscription agreements with tool vendors.
Your organization may be experiencing the phenomenon of PMOs spawning like Mogwai dropped into a swimming pool, but this should not imply that the efforts of these disparate PMOs cannot be aligned towards (what should be) a common goal – facilitating the creation of business value.
(Note: this article was originally written and published by me in December 2009 on my personal blog, kbondale.wordpress.com)