PPM: Everyone Gets To Play (Part 2)

In continuation to my previous blog post, this one will explain how the PPM needs of organizations drive the overall implementation process. At the enterprise level, we all recognize that different types of businesses execute different types of projects. The project portfolio for an investment bank is going to look a lot different from the portfolio at a company that designs and builds computer products, or a hospital, or a university. Even when we look at similar enterprises, we find differences in strategy, culture, and approach. Since many of these differences are the fuel for competitive advantage and operational excellence they require processes and practices which support those unique attributes.

Likewise, we need to recognize significant differences between functional areas  within the same enterprise due to the nature of the work being executed and the varying ways in which that work is done. The PPM needs for the product engineering groups are not exactly the same as those in HR.

Let’s take scope management as an example. For a company that is building something under a contract for another company, control over the scope of the project may be critical to assuring company profitability and in the most extreme cases the financial viability of the supplier organization. In this case, one would expect a much more structured, formalized set of processes for reviewing and approving scope changes and making changes to supporting contracts, payment schedules, etc. By contrast, when a department in one organization needs to communicate and manage expectations around delivery dates and costs for a sponsoring department within the same company – especially when the sponsoring department has requested the change — they may adopt a less formalized, lighter weight scope change process. In both situations changes the “what” of scope management is the same – scope changes need to be recognized, communicated and approved – but the “how” may be radically different.

We must also take into account that the approaches, tools and techniques used, even within a discipline may change over time. For many years, the construction industry used the Design/Bid/Build phases in their projects where each successive phase was substantially completed prior to the commencement of the next and each phase was executed by different organizations. Unfortunately, as a consequence of this approach many projects were plagued by a fourth phase, “litigation”, with finger-pointing and lawsuits between the parties to establish whether something was a defect in design or a defect in construction. Now many construction projects are using an approach called “Design/Build” where the work is performed and managed as a single, integrated effort. Similar changes have occurred in information technology, where new development tools and approaches have facilitated iterative and agile development of applications and business systems outside of the lockstep waterfall techniques of the past. Each of these has required new techniques for how the projects using them are planned and managed without losing the visibility needed for oversight and control of the outcome.

The most successful PMO’s and ePMO’s are those that understand the underlying goals and objectives of PPM while implementing supporting processes that are adapted  to the unique, changing needs of the enterprise, and the functional groups and disciplines within that enterprise. While this requires open-mindedness and creativity the adoption of PPM across multiple disciplines in thousands of companies is proof positive of the feasibility and be benefit to be derived from the effort. In short, despite the declaration of that gentleman at my first PMI meeting – PPM is relevant to Information Technology. And  to Finance, Marketing,  Professional Services,  New Product Development, Manufacturing, Supply Chain Management, Education and any other discipline or organization that invests in and executes projects. It also still applies to Construction and Engineering…

As a post-script I would add that since that first meeting I have belonged to PMI for many years and attended numerous meetings in a variety of other locations and chapters which were well attended by individuals from a wide variety of organizations and disciplines.

Effective Approaches to Project Prioritization

‘The key is not to prioritize what’s on your schedule, but to schedule your priorities’- Stephen R. Covey

Like most of us, I have a tendency to attend to tasks that interest me the most, especially when I am expected to deliver on multiple projects within the same time frame. The problem here is that, what interests me the most may not necessarily be the most important thing that needs to get done. Personal priorities help us direct our attention to activities that give us the greatest value as individuals while organizational priorities are intended to focus more on teams and on matters that provide optimal value to the organization.  Without organizational priorities, individuals will set their own priorities (like doing what they like), hence the important stuff doesn’t get done on time. Conversely, clear organizational priorities guide us better to make decisions that are ‘directionally’ correct.

Well-defined governance outlines who sets priorities for what.  While all the work in an enterprise gets prioritized by someone, there are often multiple managers or management groups that are independently prioritizing that work. While this is totally appropriate for tactical operational work, using the same approach for projects – especially cross-functional efforts – can derail project progress while project work waits for resources that are working on locally defined priorities.

Project prioritization is not tactical – it’s strategic and, as such, it is a function of portfolio governance.  Portfolio Governance Committees or Teams are typically made up of senior-level managers and as a team they are responsible for representing the broader interests of the enterprise – rather than the individual groups that they lead.  The portfolio governance team meets periodically to review the progress of high-value or strategically significant projects, consider new project
proposals, and establish or revise the priorities of projects in the portfolio.

It is important to note that the Portfolio Governance Committee is not concerned with day-to-day prioritization of work efforts but instead focuses on longer term, strategic prioritization of projects.  Short-term issues or resource conflicts are handled by tactical management teams guided by the project priorities that have been set.  For example, if a lower level project is in trouble the tactical team may temporarily redeploy resources from a higher priority project — but only to the extent that it does not impact the performance of that higher priority effort. The priority of the projects does not change – only the tactical priority of some of the work does.

The second attribute of an effective project prioritization process is having a consistent set of criteria for evaluating projects by themselves and against others.  Using consistent criteria make the prioritization process more efficient and effective since we know what information is needed before we take a project to our governing body for consideration.

While there are a number of techniques for achieving consistency in evaluation, the most popular is accomplished with a scoring model.  The scoring model consists of a set standard criteria that reflect the key attributes of a project to be considered in the prioritization process and a set of measures or ‘scores’ that will assign a value to each criteria.  For example, let’s say that one of our evaluation criteria is cost reduction. In building our scoring model we’ve decided that any project expected to reduce costs by more than $1M will receive the highest score value and any cost savings less that $10K should receive the lowest.  We can also establish intermediate score values to represent the levels between the highest and lowest levels between our highest and lowest values.   By providing the criteria with pre-defined values we have the ability to compare projects on an ‘apples to apples’ basis.

Good scoring models take a while to create – and the best ones I’ve seen generally have evolved over time as the governance team refines their view of the portfolio and the individual projects within.  If you’re building a scoring model, there are a few things to keep in mind:

  1.  Identify criteria that reflect both the potential upside and downside of the project.  While, the example cited earlier used a scoring criteria based upon a benefit (cost reduction) you also want criteria that evaluate project cost, duration or risk dimensions of the project.
  2. Consider strategic objectives in defining benefit criteria.  While many projects may seem like a good idea, if they don’t support your organizational strategy they shouldn’t score as well as those that do.
  3. Clearly define both criteria and scoring values.  Take some extra time to both define and validate the definition of your criteria – ambiguity will only create confusion and reduce the credibility of the scoring process.

While using a scoring model to evaluate projects is a high-value component of project prioritization, the score of a project and the priority of a project may not be exactly the same thing.  While the score will inform the prioritization process, external factors such as regulatory deadlines, seasonal demand, or unforeseen business opportunities may dictate that a lower-scoring project is prioritized above one with a higher score.   For example, if a project is almost done it generally makes more sense to complete it rather than putting it on hold to start a new one. While you could build all these factors into your scoring model it would be highly unlikely that you could anticipate everything and every time something came up all the projects would need to be re-scored, adding chaos and rework to the process. By establishing a priority rank (1 to n) or priority value (high,medium, low) in addition to the score you have the flexibility to accommodate minor prioritization changes without having to re-score the entire portfolio.   Even here we need to be cautious: While minor adjustments may be needed, continual, significant re-prioritization can be disruptive.

Last but not least is communication – project priorities are only useful if the people impacted by those priorities know what they are.  The individuals responsible for priority-setting are in the best position to communicate those priorities across the organization and to communicate the business rationale for them and typically will craft the message regarding initial priorities. But one-time communication is only part of the story, regular reminders are necessary to maintain focus and commitment to priorities.  Here is where an the PMO can play a significant role by reinforcing the message in obvious ways like written announcements and meetings or more subtly, like always showing the project priority in listings and reports.  Constant visibility of project priorities can go a long way to making these priorities an integral part of how projects are viewed and executed in the organization.

Establishing a project prioritization process is neither simple nor fast.  It requires a great deal of organizational buy-in and support, especially from individuals who may see prioritization as a threat to their authority and control. However, organizations that invest the time in establishing repeatable, fact-based processes for prioritizing projects find it quickly yields positive
results and is well-worth the effort.