Project management as a function is diverse. Projects cover all sectors of life; Wedding Planners are project managers that use specific tools to help plan your perfect wedding. They formally create a process to deliver the requirement as profitably as possible. Projects managed within small, medium, large and enterprise scale businesses are no different. Projects within healthcare have preferred processes and tools to compliment profitable delivery just as much as projects in Retail, IT, Finance, Government, Non-Profit, Education and so on, but the processes and tooling to deliver this can be very different.
So is there one tool that fits all – no. There are many tools focusing on many different sectors, functions and niches. For example, software development leans towards product management methodology and agile delivery practices. It can be argued the tools product managers use and the tools the delivery function uses are also project management tools. Both tools provide valuable information for a project manager and a project manager may find themselves embedded within either tool to deliver their project management responsibilities. So, are they project management tools? No. Both are tools containing data that a project manager needs and both tools may provide valuable reporting and tracking capabilities, but neither are project management tools. Neither tool was designed with project managers in mind and if a project manager is using one of those tools to deliver project management responsibilities, it is due to a lack of project management tooling capable of delivering their responsibilities.
Project managers need specific pieces of data to create information enabling scheduling, informed progress reports, risk management, financial management and decision-making capabilities to exist (to name a few needs).
Programme Managers have similar requirements, using the same (and more) data to create information for progress reporting, risk management and decision making. Further, Portfolio managers need to be able to aggregate multiple programmes and/or projects data into information for informed reporting, risk management and decision making. As a result, this article will focus on execution tools (Project), strategic tools (Portfolio, Programme) and combined tools (PPM).
Is there one tool that can do all this? Not really. Project Portfolio Management (PPM) software will claim they have one suite that can deliver across the entire strategic and execution spectrum of requirements – but this is rarely the case. PPM tooling is still relatively immature, and no single tool can deliver, nor ever will complete the requirements of a PMO function.
To get a more accurate definition of the project tooling landscape, I prefer to view through the eyes of solution architecture. Consider the development of a digital product, perhaps the ability to purchase lottery tickets online. To purchase a ticket, you need to register as a user, go through credit checks, deposit money, pick some numbers, wait for the draw, allow an algorithm to run the sequence of numbers to present a result and then assign rewards to those users that matched the sequence of numbers for the rules applied to that draw.
The lottery product is not a single tool. It is a combination of multiple pieces of software, each with a specific function, integrated and communicating with one another to provide the optimum journey for the lottery customer.
Project management is no different. For a Project manager to deliver their responsibilities as efficiently as possible, the project manager’s journey needs to be understood, the tools required revealed and an integrated solution developed. This requires a solid understanding of project management, the role and responsibilities to be played and the context with which the management is to be applied to (e.g. healthcare, financial services, retail, gambling). Not an easy task.
You may have heard of persona’s, customer experience (CX), customer journey (CJ) and storyboards in the past, particularly in the digital environment as well as the retail environments. They are key to understanding who you are delivering tooling for, what the person wants from their tool and why they need their tool to be that way.
Without these ingredients, delivering tooling is more of a guessing game and more likely to deliver some efficiencies for the intended audience and a lost opportunity for delivering optimal customer experiences.
Project, Programme and Portfolio tooling is no different. How can you deliver an optimal experience for this function? To answer this, I am going to start from the top down. In its truest form, Portfolio Management requires control over both programmes and projects to ensure it can extract data from both to serve its information needs. For example, the weekly spend of a project and/or programme can be extracted from the project report and/or programme report to enable the Portfolio to combine the sum of all projects and programmes and understand the combined Capital & Operating Expenditure on specific or all initiatives within an organisational unit.
You could have multiple Portfolio’s, each with their own programmes and projects – the same principle applies. The Portfolio control will be dictating that Capital and Operating Expenditure must be reported in a specific way for the calculation of total spend to be accurate. The Portfolio is exerting control over the programmes and projects.
To make the Programme Manager’s and/or the Project Manager’s journey as easy as possible, the Portfolio should provide the tools to allow both Customer’s to be able to provide this data as easily as possible. Further, the tooling could also provide the financial reporting for their programme and project as a benefit of submitting this data, rather than assuming these customer’s will generate these themselves.
Standardisation leads to governance frameworks which naturally leads to PMO functions to exist that will administer the governance frameworks and tools used to deliver the responsibilities agreed.
Projects and their tooling are no different to any other operating function and requires an enterprise architecture design to clearly outline all the tools that will be required to integrate with one another to allow secure flow of data interchange to enable efficient information generation.
Gartner cover PPM tooling to give you an idea of the tools out there, the leaders, the niche players, the challengers and so on. If you search for “Gartner PPM” (Gartner) as well as “Forrester PPM” – (Forrester) google images will show you Gartner’s Magic Quadrant and Forrester’s Wave for PPM tools and the list of tools and their adjudged PPM capabilities.
Portfolio and Programme Management are about strategy and planning, project management is about execution and the delivering the work. Two different skillsets that often lead to two different types of tooling. PPM tooling seeks to connect both strategic and tactical (execution) to provide an integrated view.
This sounds like the domain of enterprise and large businesses only, as they are likely to be the only groups able to afford dedicated PMO functions. Not really. Your PMO could be the tool itself.
Software as a Service (SaaS) has come a long way. SaaS companies have invested in understanding who their audience is, what the most efficient process will be to deliver the experience the customer wants. If these companies have already done it – is there a need to re-invent the wheel?
Business Process Modelling & Workflows
Business Process Modelling is the act of documenting the process the business goes through to reach an outcome. For example, what is the process the business goes through to take a business idea, gain funding to progress the idea, agree the strategy and deliver the reality? The model is the document that a Business Analyst has invested in observing who does what and how they do it. It creates a map, with multiple levels of detail, articulating how a company achieves the outcome in its current state. The analysis is working with a team of specialists across multiple functions to design a new process that will achieve the same outcome ‘better’. Better can be anything you want it to be, cheaper, quicker or with greater quality (for example). The model is the art of playing with the designs to achieve the correct balance for the organisation’s needs. This design becomes the target operating model.
SaaS companies will have identified this and deliver against a target operating model. They may not deliver the target in their first increment, instead choosing to produce incremental steps of capability along the way to reaching this goal. The SaaS company has created a roadmap to delivering the optimal customer journey. It also enables the SaaS company increase quality more quickly by acquiring customers that provide feedback on the existing capability and where it can be improved. If this feedback matches with the strategic goal (target operating model), this reinforces the value of the customer journey to be built. Feedback could provide insight into new perspectives not previously thought of which could gain approval and be incorporated into a revised target operating model. Win-Win.
The point is the effort in understanding what the customer journey is has already been done, so why reinvent the wheel? Small and Medium companies are not likely to have the business process in place and therefore are starting from scratch. If this is the case, why not incorporate templated processes into your organisation and find (or train) resources to consume those processes successfully?
For the customer’s (project managers) consuming this process, if this same process is used in other like-minded organisations, the project management skills are transferable, and the prospective organisation gains a resource more capable of producing value more quickly. Again, Win-Win.
SaaS companies that offer tools to meet project and/or programme needs tend not to feature on Gartner of Forrester reviews as they are built to deliver a specific purpose. For example, Atlassian has multiple project and portfolio management capabilities (Agile Boards, Gantt View, Portfolio for JIRA and JIRA Align) all within its own ecosystem, but you will not see this as a specific PPM tool within their assessment as it is considered a software development tool. Similarly, Aha! has extensive road mapping, reporting and workflow capabilities that can be used for portfolio, programme and project needs, but is a product management tool. Monday.com is doing well, in part due to a significant marketing campaign but also because it focuses on understanding how agency projects need to be managed. The result is an increase in marketing agencies using this tooling to deliver projects more efficiently. Project Managers put this skill on their CV, which end s up being matched as a keyword for prospective organisations that use this tool to find the right people with the right skills to deliver value for them. And this is happening across the spectrum of skills, not just project management.
Where a lot of these tools are doing well is because of custom workflow capabilities. The ease at which you can customise the existing workflows to suite your organisation’s specific needs is enabling organisations to control and manage change of their business process es with much greater velocity than before.
Some examples; in one organisation I commissioned the use of Aha! to provide the roadmapping, traceability, scheduling and reporting capabilities. Couple this to a tight integration with JIRA and Confluence, and the document management and delivery tracking were working with one another to provide a PMO capability that reduced manual effort by over 50%. It meant the project managers could focus on communicating rather than administering. Without this, weekly progress reports would be a manual exercise extracting data from these tools and using a combination of office/g-suite products to create the information in the project, programme and board reports that were required.
My point is that customer journeys that have been recognised to deliver an outcome more profitably gain traction. For smaller organisations, investing in one that has already had the thought put behind it and being part of their journey to their target operating model will enable you to have a tool that delivers just as much of a PMO capability, than larger customers that require more complex tooling capabilities as well as creating a specific team of people to administer the function. Make the technology deliver as much of the administrative needs of the function as possible.
I have used the words data and information carefully in this article. The words can be used interchangeably but it is important to understand the differences and similarities when considering what the best tooling solution will be.
Data is the core entity that can be used to mean something. If that core piece of meaning is enough, then the data is not only data, but it is providing you with the information you need. However, is that single piece of data needs to be combined with something else to give it the meaning you are looking for, then the combined pieces of data become information. Stick with me here, this piece of information may be considered data for something else; in other words, this information may be combined with another piece of information to create a new piece of information. In other words, the two pieces are now considered data objects to create a new piece of information.
Using an example from above, the amount of effort consumed by a project might be measured in time. This time has a cost associated with it. Combining these two pieces of data provides information on the overall cost of effort over that time. The overall cost of effort over that time for that project might then be combined with the overall cost of effort over that time for multiple projects to produce a piece of information that enables a portfolio manager to see the total cost of effort across all projects for that time period. The information produced at the project level has become data to produce a new piece of information at the portfolio level.
If the data for effort is one tool and the data for cost is in another, the project manager may need to use a third tool to produce the information (e.g. Excel). Four choices exist;
- Stay as you are
- Purchase a tool that allows for both pieces of data to exist in one tool, decommission the other two
- Integrate between tools to allow one tool to produce the information required
- Purchase a tool that is relevant for the project team and allow the other tools to integrate with it.
Sticking with Option 1 can work, albeit is intensive on labour and technology, creating a more costly operation. Choosing number 2 could work if the stakeholders using both tools get the same or increased benefit of using one tool. This invariably is not the case as the two tools have been built for different customer journeys and divergence is more likely to happen, leading to a failure in operating experience and most likely leading to option 1 behaviours to creep back in.
Option 3 typically happens when the business case has not correctly articulated the ROI generated by acquiring tools that allow the project managers operating journey to exist and be complimented by other tools. Further, Option 3 typically happens when the organisation simply cannot afford creating an ecosystem of data exchange and settles for delivering a short-term goal to fulfil short-term requirements.
Option 4 is the long game approach. The business case is likely to have articulated the benefits of keeping both tools as they serve and are owned by different audiences. The business case is likely to articulate that using generic tools like excel only go so far, and that by purchasing a project management tool – they are benefiting from the same situation the stakeholders that are using the other two tools for – delivering a specific customer journey. Finally, the business case should articulate the value of extensibility, the capability for the tool to allow for data to be exchanged with 3rd party systems on an ongoing basis as part of operational efficiency.
The journey for the organisation recognises the deployment of the new tool as an operational efficiency. The next stage in delivering the project managers journey will be the integration piece, delivering further operational efficiency, increasing the value of the tool to the organisation and the efficiencies the tool delivers.
Scheduling can be centralised in one tool but could get status reports on updates to the schedule from other tools sharing specific pieces of data with it. Risk management could move away from generic tools to a specific tool that can map risk scoring to produce risk models and what if analysis based upon risk to compliment impact analysis effort. Or, it can allow for excel to be used as long as standard structures are used across a multitude of projects, enabling the tool to integrate with the sheets, ingest the data it needs to produce the information required. Similar principles for financial management. Delivery tracking software could be integrated with to extract key pieces of data to inform progress reports – and so on.
Understanding what information, the customer needs, where it will get the data from and creating an information architecture that allows for an ecosystem of data exchange is the winner. SaaS companies recognise this and the value of creating API’s (Application Programming Interfaces) that allow you to extract specific pieces of data for use as information elsewhere, as well as allow for data to be ingested into it’s own software to present as information where appropriate.
It is what has led to the capability of IoT to exist as an industry. It is what has led to companies being able to use AI as a service. You plug in the data you need, the rules to run the simulation and the service will produce the results as information for you to consume. What is exciting about AI, is the ability for SaaS companies to no longer invest as much in understanding and developing logic to deliver specific pieces of information, use AI services that will crunch the data on your behalf and ingest the data back into your software to present the information you need.
The Golden Triangle
No, not the geographical definitions relating to precious metals, more People, Process and Technology (PPT). A framework for delivering organisational change. Often referred to as the Golden Triangle, it takes a top-down approach and considers people first, the processes people should consume, and the technology to deliver those processes. It is the same principle when thinking about Persona’s (People – Who), Customer Experience (Process – What) and Tooling (Technology – How).
SaaS offering that have used this principle to deliver their products deliver Software that not only lives by this principle, but also flips it on its head. To produce the software, the framework is used to identify who, what and how to produce something that people will want to buy.
Customers looking to buy their product as a tool for operational efficiency find that the tools features and associated processes offer a level of optimisation that defines the type of people to use them. In other words, a self-fulfilling cycle of people taking on the responsibilities of the persona the product that designed the company created in the first place. If the product company stops listening to customer feedback to develop the persona, then that product will have a short life.
What has this got to do with tooling? Everything. Use the golden triangle to develop tools that will be sold as tools to other people. Use the golden triangle to understand what your current and target operating models are so that you can build a tooling ecosystem that will be fit for purpose.
A final word on data. The Golden Triangle is nothing without understanding data. There are those that don’t believe in the golden triangle purely because it misses out data, there are those that believe the golden triangle itself should evolve to incorporate data. I believe it may be as simple as keeping the triangle and just adding data in the middle to show the process is not linear, has additional dimensions, and the focus of people, process and technology should always be around the data and the informational value the data will produce.
Would you like to know more?
If you found this article useful, do let me know, it will encourage me to do more. If you want me to write about anything specific on project, programme, portfolio or PMO management, get in touch. I plan to release more under the title “P4 Perspectives” so follow/subscribe to be notified for the next one.
The P4P series, and this article in the series is also published through Medium. Read Here..