Many projects, and in some organizations most projects, fall into the category of operational projects. Their principle constraint is that the processes and practices of the enterprise continue without disruption.
These projects can be quite demanding. Success is often overlooked, as being noticeable probably means you are not doing it right! Stakeholders are, in the main, ‘sleepers,’ and only become interested when there is a problem.
A classic operational project is an office move: endless planning, little senior interest, and precious little thanks from anyone. Other common examples are projects that are ‘like-for-like’ replacements of technology or capability.
From Fix-on-Failure to Planned Maintenance
When you are running a set of electricity generating power plants, maintenance can be a problem. Waiting to fix-on-failure means handling unplanned outages and crisis management—always an expensive option. So the better option is to have a policy and practice of preventative maintenance, monitoring and replacing components and sub-assemblies before a problem arises. This was the approach adopted by one large energy producer. The work program had been run by line management and the process was described by one of the senior managers in a fit of frustration as “a journey into the unknown.” No one knew how long it would take, or seemed to care. It took however long it took.
In 2010, a new board member decided to introduce project management disciplines into the mix. He knew that setting traditional project constraints such as time and cost was a futile exercise. The problems found could not be known at initiation, but there was one absolute constraint or success factor. As soon as the decision to take one of the turbines out of action was made, it had to be back online as soon as was practically possible. He had unwittingly set up the conditions for an operational project.
The planning steps were precise and followed the seven-step process discussed elsewhere in the book, and this time they were carried out in the sequence CPPRRSS, which is illustrated in Figure 8.1.
Figure 8.1 The standard CPPRRSS planning steps
The set of all possible products was known, it was after all a turbine they had put in. What wasn’t known was for any given product whether it needed to be left, repaired, or exchanged. So for each product, a set of processes that could be used were defined, and each process established which the resources, both human and other, set out in detail. The risks associated with the processes and resources were logged, and this complex set of alternatives was fed into a scheduling tool. As is usual with operational projects, the stakeholders were only interested in achieving an unremarkable outcome.
The change, however, was remarkable. The operational project approach with its planning provided a measure of control over the uncertainty. Senior management felt they were once again back in the driving seat, rather than the engineers and planned outage dropped significantly.
When It Looks Like an Operational Project…But Isn’t
In a similar way, a large insurance company had a policy of planned obsolescence for its IT kit. After five years, printers were replaced. This time, however, when the project was implemented, there was resistance. After a few months, whole departments flat out refused to co-operate, and the process and the project dragged on for more than two years. Why?
Although the original justification for the project was ‘like-for-like’ replacement and it was positioned as an operational project whose success criteria was therefore minimal disruption, it turned out there was another agenda. The Head of IT and the owner of the printer assets had her own critical success factor. She wanted to reduce costs—a genuine benefit—which is unusual for most operational projects. She also wanted to implement what to her was an important improvement—the direct allocation of printer costs as opposed to the arbitrary allocation of costs that then prevailed. Chaos, anger, and resentment! When you run operational projects, and many, many projects are operational projects, it is essential the game plan is understood. None of the planning and few of the project disciplines that flow from setting projects up as operational will support the management of significant impacts on stakeholders’ behaviors.
When Is a Project a Project?
While there are many operational projects, there are also a lot of miscreants—pieces of work masquerading as projects—that are creating havoc. Let’s consider these four common situations:
- A ‘project’ that is, in fact, a continuing series of process improvement activities.
- A ‘project’ that is a piece of work carried by just one person.
- A ‘project’ that is a standard process executed regularly, for example, creating an annual report.
- A ‘project’ set up to maintain existing equipment or systems and is:
- Carried out to prevent a problem arising (preventative maintenance).
- Carried out to fix a problem that has arisen (corrective maintenance).
- Done to improve performance (perfective maintenance)—also called ‘enhancement.’
All of these types of activities are called projects and are found in project portfolios in many organizations. They are also the source of considerable distress in these organizations as managers and members of the project community struggle with the clash between the diktat of method enforced by a control-oriented project office and commonsense.
Yes, you can show that each activity does have some management aspects in common with a project, but they really aren’t projects, and a major disservice is done by mistakenly calling them so. Let’s revisit the definition of a project and the purpose of planning in projects:
A project is a temporary organization set up to manage the inherent uncertainty caused when resources are assigned to undertake a unique and transient endeavor within a set of constraints and needs to integrate the outputs created into a changed future state that delivers beneficial outcomes. And the purpose of planning in projects is to manage those sources of uncertainty.
When you try to apply this definition to the four situations, it becomes clear that they fail on many counts. They are not temporary organizations of individuals. They have not been brought together for a unique and transient process. The constraints are usually not enforced or enforceable. And finally, and crucially, there are virtually no sources of significant uncertainty, the people doing the work are familiar users of standard processes, the solution sought is known—and no one is interested in the problem space, the requirement is to deliver the known solution.
It is worth looking in more detail at (4) maintain existing equipment or systems. When preventative maintenance is implemented as a continuous improvement program, it gains no benefit from being set up as any type of project. Corrective maintenance activities are inherently unplannable. They are transactional events that demand immediate reaction or the response can be batched with others and deferred. There are no project-like aspects in this type of work. The third type, perfective maintenance, also referred to as enhancement projects, can benefit from being dealt with as a project, but the use of project disciplines is often rightly abbreviated.
So why does it matter if these pieces of work are called and treated like projects? What’s in a name? Well, quite a bit!
Confusing Work Package Management with Project Management
At best these pieces of work are what we call ‘work packages.’ They are distinguishable from projects because, if work packages can have an objective, then the objective is to deliver the product, not a future state. The conditions of success are that the product is delivered as near defect-free as maybe, and if there is a stakeholder, then they will be the product owner. The planning, if there is any, can be wholly defined by PPS, which translates to: establish the products; set out the processes; define the schedule. The resources are preset, the risks are generic, and in truth, most of the processes are pre-determined. The dominant life cycle is not the project life cycle with its start, plan, do, close structure, but a product life cycle, be it a document, engineering, or an IT product development model, such as waterfall or Agile.
This gives rise to two concerns. The first is that using project disciplines in inappropriate circumstances leads either to their disuse or their misuse when it matters. You don’t need to be doing corrective maintenance long before you realize that planning, scheduling and the maintenance of risk logs, let alone other project disciplines, is just ‘make work.’ You just need to get on with it—it’s a lot like process management! With this lesson well learned, it gets carried over to situations where planning and structuring work using project disciplines actually does matter, but it does not get done. This may well be why planning in projects is so poorly done if done at all. The training ground of many project managers is in the management of work packages, flaunted as projects.
The other concern is that it reinforces in managers and senior managers’ minds that planning, and other documentation, is bureaucracy, a misuse of time and effort.
By managing work packages as projects, the organization either gets involved in over-governance—you do not need a sponsor or a steering group for these activities—or worse, neglect the governance of projects.
By putting work packages with projects in a single project portfolio, the organization generates, often overwhelming, competition for resources, with these urgent but relatively unimportant bits of work displacing projects with genuine benefit cases, or else creating an ever-growing backlog of items not done, to the frustration of many.
By conflating work packages with projects it legitimizes the inappropriate extension of product life cycles into project management, and history proves this is pernicious. In the 1970s, there was a surge of IT technicians into project management, which damaged and delayed the development of project management by 20 years or more. You can still see the fossil remains in many organizations today when you look at their project life cycles.
There was a product development life cycle called SSADM, which stood for structured systems analysis and design method. Heralded as a breakthrough—and it was—in formalizing and in many ways simplifying the process of creating complex software, it provided the basis for the evolution of systems engineering approaches. What became a problem was the unnatural, unwelcome, and inappropriate extension of its concepts and approach into project management.
SSADM urged that analysis comes first—a really good idea! Then design, build, and test followed by implementation. This is a sensible and organized way to produce complex products and a hopelessly incomplete—and unhelpful—way to manage a project. Yet in many organizations, even today, you can recognize SSADM stages featured in their customized and carefully crafted project life cycle. It’s no wonder when projects are run under these circumstances that they ignore stakeholders, omit closedown, forget about benefits and change! Of course, they do. Product life cycles have nothing to say about them. We could do well to heed the lesson and make sure we don’t repeat the experience as Agilists push their product development life cycle as a candidate for running projects.
The Special Concerns of Operational Projects
Operational projects are so prevalent in organizations that it is worth taking a moment to understand some of the dynamics and how they differ from other projects discussed in this book.
Operational projects are often staffed either in whole or in part by operational personnel. In fact, the individuals running these projects may not identify themselves with or as project managers. They do, and want to, use many of the project disciplines, but shy away from what they see as the bureaucracy of project method.
One distinctive aspect is how quickly these projects can slide from managed scheduled activities—where work done is organized by tasks and milestones—to become a ‘best endeavors’ piece of work. ‘Best endeavors’ means that the work will get done when it gets done—not a well-publicized project ambition! The problem is that the urgencies of operational imperatives trump what may well be the more important work of the project. And, this is exacerbated further when the project team members are also operational staff. The conflict gives rise to the observation, that for operational projects, the only genuinely hard constraint is minimum disruption, not, despite all claims to the contrary, costs, deadlines, or anything else.
Abraham Lincoln is said to have commented that if he had six hours to cut down a tree, he would spend the first four hours sharpening the axe. Just as well he was a president then because the widespread use of operational projects leads to the apparently irrational situation of the organization being too busy to improve its performance.
Reflections
Operational projects are the commonest type of project, and project-like activity encountered, with some organizations having more than 80 percent of their resources committed to them.
Consider these questions in light of your own experiences:
- How do small enhancement types of projects get started? Does your organization use any of the Agile-inspired approaches such as Kanban or tools such as Jira to prioritize take-on? Would they help?
- For the vast majority of operational projects there is little or no need to establish their strategic aspects, so using the Project Mission ModelTM is unnecessary. There are, however, risks in not using it, what do you think they might be?
- We argue that many ‘operational projects’ should be treated as work packages as they do not benefit from the use of project management disciplines. What is your experience, and what is your view on this?
- Has your organization used Agile approaches for the development of software? What do you think about the debate about Agile-based project management?
- In many operational projects, the resources available for use on the project are predetermined. How would you handle this in the CPPRRSS model?