« Six Constraints: An Enhanced Model for Project Control - Time and Cost
Supporting Frameworks for Successful Program Management - Change Impact Assesment »

Processes, Projects, and Programs - OH My!

April 6, 2008 | Author: admin | Filed under: Miscellaneous

Processes, Projects, and Programs - OH My!
By Mike Crocker

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.

Mike Crocker has combined his MS in Systems Management, PMI certification as a Project Management Professional, and his ten years experience in the web and software area to effectively lead cross functional teams developing and deploying projects that are aligned with the strategic business goals of the company. Using his experience and his love of learning, he has worked as a Project Manager in Aerospace, in the area of marketing for computer equipment, computer peripherals, and software company, wireless applications developer, international semiconductor membership organization, and a web design and hosting agency. Mike has also created and implemented Project Portfolio Management structures and tools for small companies. Mike runs the Project Management in the Dept of Doing blog.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Sunday, April 6th, 2008 and is filed under Miscellaneous. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Mike, your point that “The other is avoiding having the people working on those processes see my work as a threat” is a good one. It can really help if the software you use to manage PM processes and people can bridge the gap between managers and “civilians.” I’ve used Project Insight on a few projects and I always begin by telling the other team members that it integrates with Outlook, so their whole world doesn’t have to change. That seems to help.

Cynthia Siemens wrote on April 6, 2008 - 8:35 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories