The corporate advantages of a project management process

A project management (PM) process is a process that wraps a robust and repeatable structure around a series of events that lead to the completion or implementation of a project. In most cases, you’ll see a structured diagram that lists the project management process groups used to manage a project. I have been fortunate to study and review many PM processes over the years, from the Department of Defense to state and local government processes. In addition, I have studied and reviewed PM processes in commercial enterprises, banking, healthcare, and nuclear power. What I want to introduce is the concept of the Project Management Process and why it is beneficial to have one in your organization.

In most cases, project management (PM) processes actually serve a purpose in an organization by providing a PM process methodology in an environment where it did not formally exist. Although a corporation may have a documented SDLC (System Development Life Cycle), these are specific to system and application development and not project management. It should be noted that the projects are not exclusive to an Information Systems Department. It should also be noted that not all SDLCs adequately reflect PM processes.

According to the PMBOK (Project Management Body of Knowledge), “A project is a temporary effort undertaken to create a unique product, service, or result. These temporary and unique characteristics determine whether a particular effort is a project.” With that in mind, projects can and often do exist in many areas of an organization, with the caveat that they cannot be treated as one project under the guidelines of a “Project Management Process”. If projects exist without a PM process to reference, while they may be successful, often these projects are managed in chaos.

The purpose of a PM process is to provide organizations and project managers with a structure and format that is common and repeatable, the PM process is not specific to a business unit or corporate department. All departments should use the PM process for projects specific to them or for projects that span multiple business units.

In an enterprise process diagram, each process group could reference associated project templates that can be completed and used for project documentation. Typically, project documentation will consist of…

1. The Project Charter

2. The objectives of the project

3. Summary of a case

4. Stakeholder analysis

5. Project Scope Documentation

6. Documentation of project requirements

7. A responsibility matrix

8. A project plan

9. A communications plan

10. A risk plan

11. Meeting minutes

12. And status reports

This is not an exhaustive list, but it does give you an idea of ​​some of the types of documents you should have for a formal project.

Let’s go over a situation where project management is not used, what are some of the pitfalls? An information systems department is typical in many organizations, so a software application will be used for this example. In this case, without any PM process used, you can expect the project to be poorly documented or in some cases not documented at all, and most likely in a state of constant change. In other words, it starts with a business user meeting with an administrator and/or app developer with…we want the app to do this, and the requester presents what they want the app to do. At some point, the requester comes back and requests additional functionality. This is noticed and acted accordingly. This cycle continues until the requestor is satisfied and the request is approved and goes to production.

So far in the development phase, we can see from this example that the project is out of control, forcing the developer to be in a reactive vs. proactive state. What can happen next is often expected without a PM process. The application goes into production and suddenly something is not working as expected. This could be due to several factors. It was not fully tested before going into production because there was no documentation to reference to create a test script. However, the requester is looking for functionality that they did not request or forgot to request, and there is no reference documentation to identify what did or did not occur. There may be other reasons, but the result is the same, discouragement, discontent, along with additional time and cost to complete the project.

Again, in this example we see the project resources in a reactive state, not controlled by any formality, so there is chaos. The reality of this example is the fact that the resources are not being used effectively and the corporation will pay those additional costs financially and emotionally. Trust me, if the majority of your corporate resources are operating in this chaotic state, they will have a loss of work-life balance. Also, the quality of the product is not managed effectively, so the corporation will end up paying for that as well. The productivity of project resources is also at stake, and yes, there is a cost associated with that.

If we take this example and wrap it in a PM process, we get different results. We would create and maintain robust and documented project requirements. The project requirements will be used to develop your future test methods, with the requirements fully documented, the information you need to test in your application is already in your hands. The project manager might start with the end in mind and work backward to complete the project schedule. With software applications, incorporating the SDLC structure into the plan is good, but be sure to gather the needs and requirements of business users and include them in the plan as well.

At this stage, we have already improved the process, the documentation can be referenced to develop the application and the same documentation can be used to create the test cases. Suddenly you realize that we need to add a feature to the app that was not in the scope of the initial project, this is where the process begins. This is commonly known as change control, if used effectively a change request is made and needs approval before it can be acted upon. Once approved, this change is documented as part of the project requirements, so it can be developed but also tested in the application testing process. It is also added to the project plan and monitored accordingly. (Note that I have not gone into the risk factor discussion here, that is the subject of a future article)

PM processes provide a management structure for the information necessary to successfully complete a project. When I say “successful completion” I mean the triple constraints of project management, which are project cost, schedule, and scope involving project quality. If the outcome of a project does not live up to the quality objectives, no matter how well things went, the project could be classified as a failure.

In my research, I have learned that as an organization implements a PM process or methodology, there are associated REAL DOLLAR corporate cost savings. For example, the average cost of a project can be reduced by up to 75% compared to an undocumented process. The project schedule can be reduced by about 40%. Project resource time can be reduced by up to 75%. Then there is the quality consideration, the number of defects can be reduced by 80%. These cost, time, and quality savings occur when an organization is diligent in implementing a robust project management process. As an organization matures in its use of project management, additional cost, time, and quality savings are realized.

Let’s take a moment to put the above savings into the actual numbers. Studies indicate that if you use a project management process, your $100,000 application could have been developed for $25,000. That’s a pretty substantial saving on the budget alone, and you have $75,000 to spend on other initiatives. If a project schedule can be reduced by up to 40%, that means the project schedule of 20 weeks can be reduced to 12 weeks. With this in mind, you now have money and time to work on other initiatives. Next is project resource utilization, saving up to 75%, what took your resources 800 hours to achieve, now it takes 200 hours to achieve. You now have additional time, money, and resources for other initiatives. But wait, there’s more (as this sounds like an info-mercial), the number of defects is reduced by up to 80%. What could have been 20 product defects ends up being 4 defects. You end up with extra time, money, and resources with fewer product defects. What is happening in your company?

We are at a time when companies are specifically looking to increase business efficiency by optimizing processes. IT managers are asked to maximize the ROI of systems and align information systems with business objectives. To do this effectively, C-level executives through IT managers must understand how processes, such as project management and others, affect the overall cost of systems and applications.

In challenging economic times, corporations that have strong PM processes in place (in addition to other strong business processes) are able to focus their efforts on controlling corporate costs and increasing profits using traditional methods. Compare this to organizations that need to control costs and increase profits in addition to improving business performance, improving business information, improving security, improving efficiency, and improving service to customers, suppliers, partners, and employees. The operating costs for the latter corporation will be staggering compared to the corporation that has strong processes in place. Without robust PM processes, while projects unfold in chaos, they can be completed out of sheer heroics. Operating under this method has a corporate cost, my recommendation is to know the difference and make the right decision.