The difference between project and program management
The Project was in trouble. Established to deliver vital business transformation through the implementation of a revitalised end-to-end IT system, The Project was several months behind schedule, and well over budget. Worse still, there was scant light at the end of the tunnel. Pressure was on to deliver or heads were going to roll, and stress inside the project team was high.
In rare breaks from meetings with the CEO, COO, CIO and stream leads, the project director tried to work out what was wrong. The Project had followed PMBoK principles carefully. His PMO team had done all that could be asked. They had a detailed project schedule, updated daily, and had the missed deadlines reported against time. They had a comprehensive risk and issues log bulging at the seams. The system testing team had established a comprehensive quality control system that linked business-ratified test cases against every business requirement, and this was driving delivery of testing.
The project director knew he was driving his development teams hard, but in the main felt it was working. He felt the problem was the number of defects the teams kept encountering in the software that kept tripping up the delivery against the plan. He blamed the software vendor.
The vendor acknowledged the defects were causing issues. However, they felt this was not unexpected given the complexity of the development task, which was continually being challenged further by a stream of business change requests. Worse still, the business failed to establish a coherent set of priorities for the software development team, and had, on several occasions, re-baselined their testing requirements. The vendor felt the failure to keep the goal posts steady was the main problem. They blamed the business.
The business managers acknowledged they desperately needed the promised capabilities and were geared up and ready for the new system, but their focus was on achieving their sales targets. They were concerned about the lack of delivery and even more concerned that they would be thrown a dog of a system over the fence from the project. Although they needed the new capabilities, and were desperate for the project business productivity improvements, the last thing they could afford was to be delivered a tool that prevented their teams from selling and delivering their services effectively.
The COO was concerned: on one hand he could not afford a poor quality outcome to be delivered to the business—he had accountability for sales results, after all—on the other hand, the spiralling project costs affected his bottom line and the delays to capability delivery were unacceptable.
It was time to do things differently. The COO called an old associate who had been involved in several business transformation projects and asked her to offer some insights to their problems and what they might do about them.
After meeting all the teams and hearing their litany of problems, issues and concerns, she reported: “Your first and biggest problem is that you are trying to drive a program like a project.” He looked at her, perplexed: “I need to know who’s to blame and what to do about it, not some theoretical distinction between a project and a program!”
This example is not some fantasy tale, but the reality of a business transformation program I recently worked on. Sadly, it is not just the general populace that fail to grasp the subtle, but important differences between the management of a large project and the management of a program of work. I can’t do complete justice to these differences in one article, so I’ll seek to outline how the change in focus for this program yielded some important improvements to delivery.
In the example cited, the ‘project’ certainly did have a number of issues, including lack of scope, business requirements and some technical system challenges. It is simplistic to attribute them all to the body of work being treated as a project rather than a program but it was certainly a factor in the inability of the executive to get a handle of the root causes of the delays.
By one common definition, program management is the “effective implementation of change through multiple projects to increase distinct and measurable potential benefits for an organisation”. This is subtly, but importantly, different to the definition of a project, defined in the PMBoK as “a temporary endeavour undertaken to create a unique product, service or result”.
Although there are common themes and activities to the management of both projects and programs, there are some key differences in focus on change and benefits realisation. To tackle a program, the management challenge is to develop and communicate the ultimate change messages, understand the dependencies between related but separate projects, and conduct the symphony accordingly.
In a project, the focus is in the detail layer of understanding each technical deliverable, the activities required to deliver these, and the risks and issues associated with each and every line of activity in the schedule. Some of the key changes in the focus of management of the transformation initiative are discussed below.
Schedule management
The troubled project did have a detailed schedule in MS Project. However, it was over 5,000 lines in length, and pretty well illegible to anyone but the most dedicated of detail-minded schedulers. This was consistent with a project schedule, which is typically developed to guide activities to the delivery of the specific project objectives.
A program schedule should not be so detailed in the specific activities within each project or work-stream. Accordingly, a key plank in re-focusing the efforts to a more program aligned way of thinking was to develop a much more simplified overview of the activity streams that illustrated the dependencies of the different streams of work.
This high level program view could be understood across the business, and was then able to be used to facilitate better communications with the key business stakeholders, assist in the education of likely dates and actions required to be completed to achieve the revised target go-live date, and assist in executive decision-making.
