Processes, Projects, and Programs - OH My!

There can be confusion over the differences between an operational process, a project, and a program. In some cases this confusion is on purpose. As a Project Management consultant, I was brought in to help manage the work on one or more projects. As I dug into it, I found that some of the work was not really a project. Projects have a start, an end, deliverables, and are created to handle a specific business need. Projects can have multiple phases, projects can be used to improve and expand, and they can transition into a deployed using an operational process.

Handling multiple projects can lead to the work creeping upward into the area of Program Management. This is where the view shifts from getting the work on a project done to looking at the business strategy and how all the projects fit. The focus shifts into prioritization between projects, resource allocation on a larger scale, risk management that focuses on the impacts to the business, and the processes around starting, tracking, reporting, killing, and completing projects.

An operational process is an on-going set of tasks and most are focused on the day to day work supporting the organization. Work targeted at improving these fall into the continuous process improvement area. Because a project can be used to implement a significant change to one of these processes, there can be confusion. Some of that confusion contributes to the resistance to killing a project. It also is a factor in the reluctance to declare a project finished. This desire to call everything a project is especially strong if the business groups know that a process is not working well but do not know how to fix it. A transition from a project that is going well into a poorly run process is another reason that the business would want the project to continue.

The skill sets and expertise that makes you good at each of these is a little different. It is not difficult for the same person to be good at all three. The critical thing is to know when the work has shifted from one to another. On a recent consulting assignment, I set up the Program Management structure, creating forms, processes, and presentation formats. This provided a standardized method to request to start a project, track and report on-going projects, and prioritize the projects. On some of the projects, I was also the Project Manager, working to collect requirements, define and assign tasks, determine deliverables, etc.

I had set up and improved operational processes before, so I knew I had the expertise. But I was brought in as the Project Manager. I resisted attempts to get me to take over someone else’s area and fix the operational processes, too. I had continuous discussions explaining how a project and process are different. There were some attempts to disguise a broken process as a project. After some work and digging, I would unmask these impostors.

Setting up the program and project parts are important and a significant amount of work. The reality is that most, if not all, projects end up sitting on top of operational processes. The project initiation form collected the assumptions, constraints, and the fact that changing the processes were out of scope. The risk management documented these processes as risks items. None of that saved us. Projects became derailed, delayed, and negatively impacted because they were sitting on top of a bad process.

Next time, I will get into the mud and help shore up the process foundation. This will not be glamorous. It will also require skillfully navigating between two sharp and jagged rocks. One side is educating management that processes need repair. The other is avoiding having the people working on those processes see my work as a threat.



Technorati tags: project management; software;program management;