Structural Integrity – Setting up the right project, program and portfolio structures
This is the third blog in the series on the implementation of a PPM tool and the focus now moves towards setting up your project, program and portfolio structures. It is vitally important to think about this. Getting these relationships wrong, misaligned or inconsistently applied, can cause confusion and greatly impact the effectiveness of aggregated and/or rolled up reporting.
But what structure makes sense for you across your project, program and portfolio landscape?
What is a project and how is it defined? How do we split out (or include) business as usual activity? What constitutes a portfolio and what should go into it? Projects, programs and portfolios are often thought of as a hierarchy, with portfolios at the top, programs below and projects occupying the bottom; kind of like a pyramid. Sometimes the organisation will have guidelines (strict or not) about these relationships but often this isn’t the case. I like the pyramid model to some degree as it really shows how a project forms part of something larger and when viewed from different angles, or project management attributes like risks, resources or benefits, can have different relationships to each other and parent programs or portfolios.
There’s been much written about the definition of a project, but let’s continue this discussion and consider some of the things that we believe should be front of mind when establishing the guidelines for defining projects, programs and portfolios before you start populating your PPM tool with lots of good data.
1. What business are you in?
Firstly, what business are you in? Are you a product or service-based business? In our experience, organisations that are product-centric tend to wrestle more with the intersection of ‘project’ and ‘product’, where as service businesses seem to segregate defined change activity a little more. The rise and rise of Agile also means iterative and continuous delivery models can be applied to both product lifecycle management and project delivery, with the line becoming blurry – to good, and sometimes not so good effect. Looking to establish clarity on the “project path” and “product path” is important when considering the governance overlays required, funding models, reporting and overall lifecycle management of each. Be clear on what a product or service is and how much of the systems and governance should be shared with your PPM world.
During the discovery phase of your PPM implementation, look for all significant change activities. Try to use some basics to test these as being ‘projects’. Things like agreed start date, end date, defined outcomes/deliverables, approved budgets, etc. will help identify potential projects if they are not clearly defined. Collate this data and if you have one, work with your executive or sponsor to agree the list. Where you have business as usual activities that require significant resourcing, carry risk or have large deliverables, it may make sense to include these to some degree to ensure when you roll the data up, you get a full view of resource allocation, risk profile, bottlenecks or periods of high work intensity. Also look at the status of these activities. At the highest level you have Ideation (pipeline/ideas management) Delivery and Closure. Identify where these initiatives are in these phases and structure accordingly. It makes sense to establish some degree of gating to ensure activities receive the right level of governance and reporting oversight.
There are a number of things we look for when working with clients on this area of system set up. Some programs are known as such and they can be set up straight away with timeframes, resources and budgets allocated and projects assigned immediately or over time as they are initialised. If this is not the case, it can make sense to create a program when you have:
– High interdependence and/or dependencies between projects and in some case BAU activity
– A reasonable number of projects in similar areas
– The overall change or outcome(s) being sort is contributed to by a number of projects
– Realising benefits or managing associated risks/issues is easier
– The timeframe is known
– Sequencing, work streams or tranches makes sense
Simply, if these conditions are met, it’s likely a program will be the most effective way to manage these collection of projects. Coordinating activity; accelerating, stopping, slowing, killing or changing scope can be done on a ‘per project’ basis for the overall good of the collective outcome. With the fundamental data in place at the project level, program aggregation should provide great insights into better managing project variables.
Similar to programs in some ways, portfolios can be incredibly powerful in creating relevant views of your project/program landscape. A lens if you will, portfolios can be tailored to specific stakeholder interests, geographies, business units, product categories, funding sources… pretty much whatever is required. Creating a view that enables easier coordination, management of interdependencies and assuring change outcomes should be the main reasons for creating portfolios. Engage with key stakeholders to create portfolios that reflect the organisation’s business or operational goals, while allowing the visibility of constraints imposed by internal/external customers, strategies or other factors. If project data is maintained and regularly updated/reviewed, aggregation to portfolio level should allow for a comprehensive view of combined financials, risks, resources and many other project data attributes.
Creating guidelines and adhering to a project / program / portfolio structure that makes sense in terms of project delivery coordination, risks/dependency management and benefits realisation, is the foundation for structural data integrity. A project portfolio containing fully-managed initiatives that underpin the strategy makes the most out of the data in your PPM tool. Setting up and maintaining these structures will ensure reporting and analytics provides productive, insightful, actionable insights for communication with all key stakeholders.
To extend the discussion or to offer any more viewpoints, contact me directly at email@example.com.
Please feel free to leave comments.