Easy in theory, difficult in practice

One of the distinguishing characteristics of project work is that we are usually expected to deliver value in uncertain conditions while facing multiple constraints. While it is important for a team to understand the external constraints they have and to define realistic plans based on those, it is also advisable that they have an idea of the relative priority of these constraints before making delivery commitments.

A typical sponsor or customer might tell you that all constraints are equally important to them, there is always one or at most two which will trump the others. If the team doesn't take the effort to dig deep with stakeholders to understand the relative priority of constraints, they will be missing a valuable input for their analysis when an issue crops up which makes it impossible to achieve all of a project's objectives.

For example, if we have an issue which will affect cost, schedule and quality, without understanding which of these three is more important than the others, we may come up with a recommendation which won't result in a successful project.

And rarely do we find that all of our stakeholders will align on this relative ranking, especially with discretionary projects. Finance departments are likely to prioritize revenue and cost whereas business or product owners might emphasize timely delivery, scope or customer satisfaction. Achieving alignment between the key stakeholders might be difficult in the early stages of a project, but it is better than having those conversations when things have gone wrong and there is time sensitivity on making a good decision on how to proceed.

Even though there are many possible constraints for most projects, I wanted to get some feedback from practitioners on which of the most common ones were the highest priority on their most recent projects.

While the project management iron triangle might represent the best known set of constraints, for the majority of the projects I've been involved with, stakeholder satisfaction was the primary constraint.

I ran a one week poll in PMI's Project, Program and Portfolio Management discussion group on LinkedIn and within the ProjectManagement.com community. I received a total of 128 responses with 30% support for stakeholder satisfaction, 28% for time, 26% for scope or quality and only 16% for cost. A few respondents provided comments explaining their voting choice, but no additional constraints were provided as a primary choice by these practitioners.

Although stakeholder satisfaction doesn't surprise me given my past experience, I would have expected cost to trump time or scope. This is what I've witnessed on many public sector projects where budgets are fixed, but there might be willingness to delay a milestone or reduce scope if that means staying within budget.

"Now you know. And knowing is half the battle." - G.I. Joe

I've often referenced Dr. David Hillson's definition of risk as "uncertainty that matters" in my articles about project risk management.

The last word in that short sentence is critical.

If stakeholders don't feel that the information presented to them about a risk matters to them, they will ignore it. At best, this means the effort which the project team spent on identifying, analyzing, and communicating risks was wasted, but at worst, it could result in a stakeholder not implementing a recommended risk response.

There are many reasons that risk information might not matter to stakeholders. Here are just a few:

• Risk event descriptions are too vague
• Information about critical risks is lost in a sea of trivial risks
• Stakeholder interests or their risk tolerance level is not taken into account
• They haven't been educated about the value of risk management
• The cost of prevention or reduction outweighs the costs of risk realization

But one of the most damaging and prevalent causes I've experienced is when the information provided to stakeholders is out of date.

As with everything else on projects, risks change over the life of a project and if stakeholders are aware that the details reflected in a risk register or in a project status report or dashboard don't reflect current realities, the team's credibility will be hurt. And, if those stakeholders were skeptical about risk management to begin with, this will just give them ammunition to ignore risk response responsibilities in the future.

To get a sense as to what others were experiencing, I ran a one week poll in PMI's LinkedIn Project, Program and Portfolio Management discussion group and in the ProjectManagement.com community asking practitioners how frequently were risk registers reviewed and updated with stakeholders.

Context counts - for example, a lower complexity project might have fewer register updates than a higher complexity one.

Out of the one hundred responses received, 34% indicated a weekly or shorter update cycle, 41% voted for monthly, 21% indicated quarterly or more infrequently and 4% indicated risks were never updated.

While it is encouraging that three quarters of the practitioners were at least updating risk information monthly which might be appropriate for long duration projects, the fact that a quarter of the responses showed either very infrequent or no updates is unfortunate.

While there is some limited value in sharing risk information in the early days of a project, as complexity grows, the likelihood of not experiencing an issue which could have been addressed through more proactive risk management increases dramatically.

A ounce of prevention is worth a pound of cure, but only if that prevention is practiced over the life of the project.

Most project managers will include some contingency reserves within their budget to offset the negative financial impacts of realized risks. Determining how much to put aside for a rainy day might be done from a top-down method such as using a flat percentage derived from past projects (e.g. low complexity projects will have 10% contingency whereas higher complexity ones will have 25% contingency) or a bottom-up approach based on assessing and aggregating the expected monetary value of the financial impacts from key risks.

But, how is the contingency allocated over time and released back to the funding organization if unused?

There are four common approaches which I've encountered:

1. Allocated as a single lump sum (i.e. not time sequenced) and held for the life of the project. In other words, contingency reserves are not released back till the project is completed.
2. Allocated to specific milestones or project phases and held for the life of the project.
3. Allocated as a single lump sum, but returned back at a gradual pace based on the actual realization of risks over the project's life.
4. Allocated to specific milestones or project phases with unused amounts being returned as each milestone is accomplished or phase completed.

#1 and #4 are the two which I'd most frequently witnessed, but as usual, I wanted to compare my experience with that of the broader project management community.

I ran a one week poll in both PMI's LinkedIn Project, Program and Portfolio Management discussion group as well as in the ProjectManagement.com community. I received 56 responses with the following distribution:

• 45% voted for the single lump sum with no returns till the project's end
• 35% voted for the time sequenced sums with returns based on milestone or phase completion
• 13% voted for the single lump sum with gradual returns
• 7% voted for the time sequenced sums with no returns till the project's end

This matches my experience, but I was pleasantly surprised to see the fourth option receiving over a third of the votes as it does indicate a higher level of capability than I'd expected. Of course, this might also be the result of a bias in the polling sample towards more knowledgeable practitioners.

I did receive two insightful comments on the poll.

The first was that it depends on what consequences exist for budgetary over and under runs. The greater the penalty, the more likely that contingency reserves will be retained and fully utilized over the life of a project.

The other comment indicated that as reserves are tied to risks, some risks may not have a single expected realization time and hence it might become difficult to purely allocate contingency reserve amounts at the milestone or phase level and the bulk might end up tied to the final completion of the project.

While it is much easier to calculate a single lump sum for contingency reserves, this does not provide financial authorities with a forecast of when those reserves might be utilized and at what pace. And while risk-averse project managers might be reluctant to give back reserves until the project is done, they need to understand that reserving those funds for longer than is needed will represent a significant opportunity cost to the organization.

One of the rules in Jerry Madden from NASA's one hundred rules for project managers reads "All problems are solvable in time, so make sure you have enough schedule contingency—if you don’t, the next project manager that takes your place will."

While in some cases you will have a project which absolutely can't end a day late (think Bruce Willis and Ben Affleck trying to prevent that planet-killer asteroid from hitting Earth in Armageddon), schedule delays will rarely mean the end of the world. However, go materially over budget and you'll wish that asteroid was about to hit the planet to save you from the dressing down you'll receive from your funding authorities!

Projects provide a great opportunity for teams to develop new skills and to learn what works and what doesn't in a given context. But to truly institutionalize the knowledge gained by a given team, it needs to be communicated to others so that they might also benefit.

I've written a number of articles in the past about the challenges which delivery organizations face with learning lessons from past projects, and how these lessons are disseminated can make a big difference in value realization.

Four of the common approaches for doing this are:

• Capturing learnings within an individual information repository (e.g. wiki, standalone document) for each team
• Capturing learnings within a single, centralized information repository (e.g. knowledge base, database, wiki) for all teams
• Communicating learnings of interest to a specific skill set via Community of Practice meetings
• Embed learnings by updating or creating templates, checklists, standards or policies

The first approach is by far the simplest to implement and is highly effective for the team itself. However, it is usually useless for other teams as they will either lack the awareness or the motivation to locate and review multiple repositories in the hopes of locating a valuable learning. Additionally, when team-specific repositories are used, context regarding lessons might not be captured which will make it quite difficult for other teams to know whether a given lessons might apply to them or not.

The second approach requires more effort on the part of each team to adhere to a common learning format including the context surrounding each learning, and if the updates to the repository go through a quality review process by a different team such as a PMO, this administrative overhead might discourage teams from contributing many lessons. Assuming the centralized repository has good search capabilities and teams are able to subscribe to receive new lessons matching criteria they've provided, it can be useful. However, just because you build (and populate) it doesn't mean, they will come and use it.

The third approach works well for both tacit and implicit knowledge and the live format enables the participants from other teams to ask questions to understand whether a given lesson is applicable or not. However, unless there is some attempt to capture the discussions and make them easily available for practitioners who were unable to attend the session, the knowledge will only be gained by those present.

Finally, embedding learnings has the benefit of eliminating any effort on the part of other teams as they will benefit merely by using the updated versions of the organization assets. However, it may require significant effort on the part of the contributing team and whatever standards governance groups exist within the organization.

As usual, I wanted to understand which approaches were most commonly used in practice. I ran a one week poll in PMI's LinkedIn Project, Program and Portfolio Management discussion group as well as in the ProjectManagement.com community. Out of the 38 responses received, 45% used Community of Practice meetings as their primary approach, 26% used a separate information repository per team, 16% had a single, centralized repository and only 13% updated organization assets based on team learnings.

I also requested respondents to leave a comment if they used a different approach. While none of those who commented provided a completely new method of sharing learnings, a few indicated that they used a combination of methods. While this does take more effort, it is a highly effective strategy as it allows the optimal approach to be used for the type of lesson and it can mitigate the downsides of picking a single strategy.

When it comes to increasing organizational delivery capability, sharing lessons is truly caring!

When a project is bigger than can be delivered efficiently with a single large team, it is common practice to divide the work among a number of smaller teams. While the coordination overhead of managing multiple teams is introduced, doing so reduces the effort involved in keeping everyone within each team aligned towards a shared goal. It also reduces the potential for unhealthy conflict and could increase individual ownership for work items. It might also lead to better collaboration between team members.

But once the decision has been taken to split work across a number of teams, what options are available?

Three common methods are to:

• Divide the features or capabilities making up the scope of the project. This is splitting the "what".
• Divide the project along solution/design or skill lines. This is splitting the "how" or "what".
• A combination of the previous two approaches

If we decide to take a scope-centric approach to dividing work, the benefits are that it is possible for the team to work independently to deliver a complete feature end-to-end and be able to release it without waiting for other teams to complete their portions. This approach also enables a team and their "voice of the stakeholders" (e.g. Product Owner, Business Lead) to develop deep business expertise of a specific area of the overall product, service or result.

Disadvantages are that such teams could end up producing components which don't fit together well to form a coherent whole unless there are frequent coordination checkpoints between the teams. There might also be inconsistencies in how similar aspects of the components (e.g. user experience) are handled, and redundancy when the same enabling capability is built by more than one team for their needs. Finally, if there is limited capacity of a skill set required by all teams, it might be difficult to construct "whole" teams with dedicated staffing.

When we divide the project along solution (e.g. database, middleware, user presentation) or skill-based lines, the advantages and disadvantages are the opposite of what they were for the scope-centric approach. This model works well when you have limited capacity of specific skills, it can also develop deep technical acumen within the team and reduces the likelihood of inconsistent or redundant outputs. However, it does significant increase intra-team coordination efforts and could delay the ability to get feedback from external stakeholders on completed features or capabilities.

To address this, some leaders will take the approach of starting with a solution or skill-based approach until sufficient enabling components and standards have been built to enable effective use of scope-centric teams.

As usual, I wanted to compare my experience with that of others. I ran a one week poll in both PMI's LinkedIn Project, Program and Portfolio Management discussion group and the ProjectManagement.com community asking respondents to pick which of the three approaches they had used in their last large project. I also provide a fourth choice encouraging practitioners to share any alternative methods they had utilized instead of the three common choices.

The poll received only 41 responses and of those, 56% indicated both scope and solution or skills-centric approaches had been used. 24% indicated a solely scope-centric approach and 15% a solely solution or skills-centric approach. 5% picked the "other" choice, with one respondent providing a different method which was to distribute work based on a regional approach. This approach will work well when region-specific requirements can best be handled by having local teams and where there is expected to be little integration of outputs between the regions.

If there are other approaches which you have used in your recent projects, I'd encourage you to share those in the comments.