To avoid a dire fate, don’t forget to iterate!

Anyone who has read the PMBOK Guide or taken the PMP exam knows that project management is made up of an interconnected and iterative set of processes. Even a highly predictable project requires a team to iterate back to earlier executed processes when faced with a change request.

So why is it that we tend to forget to re-execute certain key project management processes? It’s likely because they aren’t as well understood by our team, sponsor and other key stakeholders. It’s rare that maintaining schedule or financial baselines and forecasting these project dimensions is neglected as there are usually external forces ensuring that this occurs periodically.

But let’s think about risk and stakeholder identification and analysis. Just like developing a schedule or a budget, these processes are commonly performed early in the life of our projects. But it is very common to find projects where these processes are never revisited.

The risk of ignoring them is significant.

Skipping out on full lifecycle risk management means we could continue to invest in monitoring obsolete risks while remaining blissfully unaware of new threats or opportunities. We might also be missing changes in the profile of existing risks. Some low risks on our watch-list might have increased in severity whereas others which we are actively responding to could have dropped in priority. As risk responses are implemented we want to understand what residual risk remains and update our knowledge of these risks accordingly.

The same holds true for stakeholder information and engagement activities. We might miss a new highly influential or impactful stakeholder that arrives on the scene after our initial stakeholder analysis. Or a stakeholder whom we felt had little interest in our project might become more visible than before.

We expect that overall risk and the relative influence of stakeholders should decrease over the life of a project as we start delivering scope and uncertainty decreases but if we keep looking in our rear view mirrors we are likely to miss the runaway Mack truck bearing down on us.

Avoiding this requires discipline on the part of the project manager. Consciously challenging themselves and the team to periodically revisit risk and stakeholder registers for currency and accuracy can reduce the likelihood of occurrence.

To extend Donald Rumsfeld’s famous taxonomy, we create unknown-knowns by not iterating back through all applicable project management processes.

Categories: Project Management | Tags: , , | 1 Comment

Minimal sufficiency applies to tooling just as much as it does to documentation!

“Working software over comprehensive documentation”

This value statement from the Manifesto for Agile Software Development is a reminder to remain vigilant that the by-products of our product or project processes don’t distract us from delighting our customers and stakeholders. For organizations which have onerous, document-based delivery standards, it serves as a guiding principle to lean out methodologies focusing on the minimal set of information required to meet delivery and control needs. This is usually accomplished through elimination, consolidation and streamlining of documents.

But what about those companies who have implemented tooling to support delivery in place of documentation? Just because we have moved from standalone documents to one or more supporting applications doesn’t mean we should not apply the same principle of minimal sufficiency.

Here are three ways I’ve witnessed this principle ignored:

  • Multiple point solutions with overlapping data elements, conflicting workflows, and differing nomenclature. This often occurs when delivery tooling is procured in a distributed manner. For example, a Business Analysis leader might select a requirements tool, a Quality Control manager has procured a test case and defect management tool and so on. Project teams get confused by how the different tools connect together and the likelihood of data accuracy, consistency and completeness defects increases. While detailed reporting can usually be managed easily, project/product-wide or portfolio-level reporting becomes extremely difficult.
  • Not disabling the fields and features which are not required. You might ask who would fill out a field or use a feature which they don’t need to, but you’d be surprised at the creativity of teams at using unused fields as a means of ferreting away some information they believe is valuable. Beyond the potential for field or feature abuse, a bigger concern is team members getting distracted or overwhelmed by the complexity of a solution.
  • Tooling which does not map to the information needs of team members. Its become a cliché, but one which continues to be ignored – don’t buy and implement a tool if you don’t understand the process it will be supporting! If the tooling does not help team members do delivery activities, then they will treat it as an afterthought and continue to use more useful, home-grown solutions.

I am not encouraging the development of delivery tooling in house or engaging in significant customizations to third-party applications as neither approach is appropriate for most organizations. It does mean you should be spending some effort up front to identify the key data elements which will be needed by different contributors to the delivery process, defining the minimal set of reporting and workflows required, involving an actual delivery team in the tools evaluation process, and working with vendors to safely disable or hide all non-essential features.

So before patting yourself on the back that you’ve migrated from delivery documentation to online information make sure that you haven’t just replaced one source of waste with another!


Categories: Agile, Project Management | Tags: , | 2 Comments

Improving portfolio management must be part of an agile transformation

When we think of an agile transformation, improving portfolio management might not be high on the organization’s list of priorities.

But what happens if your organization doesn’t have an effective and efficient portfolio management capability?

There is a greater likelihood of having too many active projects which increases the risk of resource shortages. Instead of having a dedicated team of primary roles for a project, most team members will be multitasking between multiple projects. This makes it impossible to accurately estimate capacity during iteration planning and usually contributes to a team missing their iteration commitments resulting in delivery delays. Multitasking also increases the effort to have a consistent understanding of the product and can impact quality as team members might be delivering based on stale knowledge.

If multitasking is not a concern, stealth or low value pet projects might be consuming resource capacity which is required to effective staff more strategic projects. This will cause delays to these projects.

Finally, for secondary non-dedicated roles which are needed to contribute to specific work items only, a lack of visibility into when they are becoming available will be a further source of delay.

If governance committees aren’t selecting the right projects which are in alignment with strategic objectives, and only kicking off as many projects as can be effectively staffed, it won’t matter how efficient, empowering or customer-centric the organization’s delivery practices are. In addition, if the existing portfolio governance practices are inefficient and onerous, by the time a team has finally received funding approval to get started with delivery, they might have insufficient time left to deliver even minimal value to exploit a market opportunity or to meet a regulatory deadline.

Portfolio plans are useless, portfolio planning is indispensable.

Rather than having business executives, finance analysts and PMO staff spending weeks coming up with the perfect roster of projects for the next year only to realize a month or two into the year that their plans have been disrupted by domino effect delays, new priorities or resource shortfalls, portfolio planning needs to be an ongoing activity. To enable this, a lean but effective resource capacity management capability also needs to be in place to ensure that portfolio decisions are being made based on a current and accurate understanding of resource availability.

Agile delivery is not a silver bullet.


Categories: Agile, Facilitating Organization Change, Project Portfolio Management | Tags: , , | 1 Comment

Blog at

%d bloggers like this: