In broad strokes here is a short history of PPPM in IT. A thing to keep in mind regarding this journey is that each stage is like a rolling stone gathering moss, at each turn many of the old useful practices and systems are kept in place.
1. Amateur hour – awareness
In the early days of IT, there were low expectations and quite often poor results. Much research was done on why projects failed. Project management was immature and the technology dominated, because it was so new. With reports like the Standish report on project chaos, a new awareness of how bad many projects were run shepherded in a new era of more disciplined project management as a whole.
2. Professional (traditional) Project Management
The entry of the Project Management Institute and the PMP certification has had a strong and profound effect on the quality of planning and project management in general. For anyone who has had to pass the test, it’s a trial of the first order. I remember it well. Certainly, it has become the de facto standard for professionals in the planning space. Yet whilst it solved tactical issues, a lot of problems in delivery still existed and failures still occurred. During this stage of evolution (which is very much still with us), tools such as MS Project and Excel for control logs tackling issue and risk management, became prevalent and mostly still in use today. Projects were and are mainly managed in isolation. In addition, there are stages in the project lifecycle where certain types of tasks need to be completed. The cone of uncertainty dominates thinking – initial estimates would be based on assumptions and scientifically whittled down to more precise estimates then ultimately delivered. Of course, when everything changes, that’s where the trouble starts. In my view, this kind of planning places an emphasis on scope management.
3. Portfolio
Enter the third stage of maturity; portfolio management. In this world, the key strategy is to capture all the project work and costs. Systems such as Planview or Clarity have prevailed. A typical process is that every project’s budget is loaded into the system and all of the staff are assigned. It’s then actually similar to an accounting system. Does the approved spend on IT cover the assigned staff? PMs effectively identify who they need on their projects and then staff managers intercede and approve. Status is often reported in the system as well. These systems can be considered the equivalent of an ERP for IT. If you have ever used one though, at an enterprise level, you would have likely seen the pain to make them work. Furthermore, for most, the question is whether, in the end, they represent real truth; since very little actual collaboration or work is done in them. Project Managers will tell you that they manage plans in MS Project, track time in a separate system, create Powerpoint status reports, enter resource management info and status again via the IT ERP and so on. In fact, the endless bureaucracy of status reporting and Powerpoint decks can quite literally drive PMs crazy.
4. Agility
There is a great line in Top Gun; ” I feel the need, the need for speed!” In the last five years, there has been a great amount of pressure to move to a more agile approach to development – away from what has been labeled “the waterfall mindset”. We love Jira and there is no doubt that it’s the most widely used Agile planning tool in the market today; see Dominators, Pretenders and Legacy Agile Tools. Yet the reality is that Agile is really a technique which emphasizes certain processes and behaviors that lead to better, faster development or delivery. It’s great but the question is whether it scales or whether there is some overall superstructure such as SAFe that provides a universal answer. However, the further you move away from the nucleus of an agile team, the less the principles seem to apply, especially at the portfolio level. There is no question that Agile estimation principles – such as transparency and devops have greatly contributed to improving IT. But Agile teams moving at different speeds, present some interesting challenges for portfolio managers. Agility emphasizes above all else speed – real code over designs for instance. This, of course, is antithetical to the Portfolio managers who emphasize cost and control.
So where does that leave us?
Let’s go back to that old triple constraint model. Basically, each stage of evolution and the tools that support them tend to lean towards certain aspects of the triple constraint model. In addition, certain stakeholders adopt tools for various purposes and can perhaps unwittingly bias the view of what is happening in their universe. Another idea is to replace quality – which of course is important with the truth. It’s the truth we want most when we plan or implement a plan – not the filtered perspective of how much something costs, how long it takes or what it delivers. 
All of this adds up to a new era of planning and management that emphasizes a focus on supporting the executional elements of project management and the scaled truth of what that means, rather than fragmented systems representing different versions of the overall truth. It’s easiest understood by contemplating how such a truth is best achieved. Some use cases best explain this –
- Track time against the actual work being done
- Aggregate results from where they are derived
- Planners and developers and business teams working off the same milestones
- Planning methods suitable for the type of plans needed
- Compare reported status to actual real-time metrics
- End to end integration and traceability to operations such as devops systems like code repositories
- Incorporation of knowledge management and documentation
Starting to sound familiar?
To achieve these features we really need everyone working in one system. To do that you need a very flexible application. That’s where Jira comes into play. Firstly, in numerous companies today, many if not most developers are there already. Yet if we are to achieve this goal we really need to provide the necessary tools for all teams rather than take an overly strict definition of what can and can’t be done using it. The good news is that with all of the add-ons available in the Atlassian world, there is something for everyone. This also calls for Atlassian stack owners in their organizations to embrace add-ons (safely). If you need Gantt charts, issue logs, risk management, budgets or time management it can all be in one place; Jira and by context linked to its sister application, Confluence from a knowledge management and collaboration perspective. This then enables ubiquity – or ubiquitous planning and management.
Call to action – tread carefully
Many enterprise systems such as Clarity have taken a lot of effort to set up (no matter how unpopular) and so for the best way to create a ubiquitous planning & management model is to start from the ground up as the diagram below portrays. In this model, Jira becomes the book of record that will send out data to other portfolio and planning “dependent” systems and then ultimately replaces them. The following stages are good milestones to work towards – every organization is different and will take various amounts of time to get to the desired state of real-time, ubiquitous PPM.
And remember !!
If you want to find out more about how Blended Perspectives can help you with best project management practices, contact us today!
– – –
Blended Perspectives is Canada’s largest Atlassian Solution Partner providing Consulting, Managed Hosting, Installation, Data Migration, Performance Tuning and Certified Atlassian training. We have deep expertise in all Atlassian products with certified experts covering the full lifecycle for SDLC, Service Desk and broader business application support.
Founded in 2007 after years of experience serving clients in Canada, Europe, USA and Australia; Blended Perspectives’ mission is to enable Corporations to unleash the power of their teams and to leverage the true potential of their business via enhanced tools and processes.