by: Clive Longbottom
Agile and DevOps approaches mean large projects with a defined endpoint are disappearing. How is project management changing?
Managing projects can be a headache for any manager, and maintaining adequate visibility over a portfolio of projects can be stressful for the best CIO.
In the past, project management software such as Microsoft Project, Primavera or Project Manager
Workbench were sufficient for most long-running projects. Gantt charts and task lists ensured critical paths were maintained; changes to the plans could be mapped and tracked and the impact on the final outcome could be estimated with the final delivery date changed, if required.
However, there has to be a change in the way projects are carried out. Agile and development and operations, or DevOps, approaches mean large projects with a defined endpoint are fast disappearing – managing smaller chunks of work and seeing how they all operate together is becoming more important.
This should, of course, always have been the case. The “eating the elephant” phrase of breaking everything down into small bits and managing each part simultaneously is how successful projects managed have typically been managed.
Yet, in many cases, it is only the total project that is addressed; the tasks that make up the processes of the project are hardly managed at all. This is most visible in the public sector, where many projects have been set up to run over several years.
As time goes on, users need change – yet the desired end result remains the same in the project plan, and the sum of the changes makes it seem as though the desired outcome will never be reached.
In the end, what should be a highly flexible approach turns in on itself, attempting to bring in the required changes but still aiming at what is now the wrong result – and the actual result is a failure of the project at high cost to the users and, in the case of the public sector, the taxpayer.
What is now required is a means of managing at the task level with a mechanism for aggregating the tasks into the processes and seeing what the impact on any end result will be. This requires more intelligence than just project management – it starts to fall into the project portfolio management (PPM) space. Indeed, in certain circumstances, if the project team can regard what it is doing as a “product”, then the better tool to choose could well be a product life cycle management (PLM) one. The key things to look for when choosing a tool are as follows.
High levels of granularity
A project is made up of a set of smaller functional processes. Each of these processes is made up of tasks. Tasks can be carried out by individuals; processes may require interaction between individuals to work together as teams; the result of the various teams’ output will be the project itself. Therefore, the software chosen must be able to deal not only with individuals and teams, but the interactions between them.
Projects are dependent on resources. These resources will include money, people, time and the physical availability of goods such as servers, software and space and power in the datacentre. Each resource must be understood by the project software – as well as the context between them. This means that when a change is applied to a task, the impact of this at all levels of the project must be understood. But does this mean that more people, money or time will be required to complete the task? And what does this mean to the overall project?
Putting together a project that solves your issues “now” is fine. The problem is that a project takes time and the end result may be an attempt to solve problems that have changed or are no longer there.
Therefore, any change requests must be seen as being a core part of any project, and the project software chosen must not only be capable of embracing these changes, but also of calculating what this means at the resource level and providing sufficient feedback to CIOs, project leaders and team members so decisions can be made over whether the change can be adopted or if there is too much risk to the overall project in adopting it.
This is known as “consequence modelling”, and may include such aspects as Monte Carlo modelling, probability encoding, risk tolerance estimating and so on.
Integration and auditing
Any project software must be capable of acting as a central control module to other systems. For example, in an IT project, using project software to initiate a code implementation through a software management tool, such as IBM Rational or Eclipse, means the action can be fully audited as part of the project, rather than as part of the development process.
Integrating the project software into any trouble ticketing system again means that an audit can be carried out in one central place, rather than across multiple systems.
Reporting is essential
Actions taken at the individual, team and overall project level must be able to be logged and reported on. Reporting is a key area, as only through suitable reporting can the impact of any task slippages or changes be seen.
Advanced project software should be able to provide some form of predictive capability, along with advisory information – for example, if a change is adopted and has an impact on the project dates, then what does this mean to the project in hard costs, and what does it mean to the business as well?
Support for rolling projects
Many projects will still have a hard endpoint, where the desired outcome is reached, but in today’s more flexible agile/DevOps world, it is more likely that various projects will remain interlinked and will change as time goes on. Being able to manage a full portfolio of projects on an ongoing level is more of a requirement than it has been in the past – and it does mean project managers and CIOs need to change their attitude to projects as well.
At the PPM level, Microsoft has built a lot of the required capabilities into its Project suite to create enterprise project management, which can be seen as a true PPM offering. CA Technologies, with its Clarity PPM software, is a major player in the space. Oracle has a range of offerings, including Primavera. Deltek, which is more focused on non-IT projects, has a strong offering that can be used by IT for managing its projects.
PLM often brings in better resource capabilities. As PLM is more often used where a physical product is involved, it is used to dealing with bills of materials (BOMs). These BOMs provide full lists of what is required to make the product.
With the right information included in the models, these provide the details needed to estimate how much the product will cost in terms of components. They also allow a full supply chain model to be built up that reflects the other resources of time and people availability. Taking a “soft” project such as an IT project, and using code stubs and functional components as basic feeds into a
BOM, gives highly granular capabilities in managing an agile/DevOps project.
Main suppliers in the PLM space include Siemens Software, PTC and Aras. Most companies in the CAD/CAM space – including Dassault, Bentley and Autodesk – have capabilities in the PLM space, but their systems may be too focused on the CAD/CAM and product space to be used as an IT PLM tool.
The concept of an IT project is changing rapidly, and many of the project management software suppliers have struggled to keep up with what has been happening. However, there are many options available to the IT project manager – choosing the right strategic solution to support a highly flexible and dynamic IT environment based around agile and DevOps approaches just requires a little more thought than before.
About the Author
Clive Longbottom is services director at analyst Quocirca.
Powered by Facebook Comments