~ By William Thom
A Project Management (PM) process is a process that wraps sound and repeatable structure around a series of events that lead to a projects completion or implementation. In most cases, you will 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 Defence to State and Local government processes. In addition, I have studied and reviewed PM processes in business enterprises, banking, health care and nuclear power. What I want to present, is the concept of the Project Management Process and why is it beneficial to have one in place in your organisation.
In most cases Project Management (PM) processes actually serve a purpose in an organisation by providing a PM process methodology in an environment where one did not formally exist. Though a corporation may have a SDLC (Systems Development Life Cycle) documented, these are specific to systems and application development and not project management. It should be kindly noted that projects are not exclusive to an Information Systems Department. It should also be noted that not all SDLC's properly reflect PM Processes.
According to the PMBOK (Project Management Body of Knowledge),
A project is a temporary endeavour undertaken to create a unique product, service, or result. These temporary and unique characteristics determine if a particular endeavour is a project. With that in mind, projects can exist in many areas of an organisation and many times they do, with the caveat that they may not be treated as a project under the guidelines of a "Project Management Process." If projects exist without a PM process to reference, though they can be successful, often times these projects are managed in chaos.
The purpose of a PM process is to provide organisations 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. The PM process should be used by all departments for projects specific to them or for projects that reach across multiple business units.
In a corporate process diagram, each process group could refer to associated project templates that can be completed and used for project documentation. Typically project documentation will consist of:
This is not an all inclusive list but it gives you an idea of some of the types of documents you should have for a formal project.
Let us review a situation where project management is not used, what are some of the pitfalls? An Information Systems Department is typical in many organisations so a software application will be used for this example. In this case, without any PM processes 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, you start out with a business user meeting with a manager and/or application developer with…we want the application to do this, and the requester presents what they want the application to do. At some point in time the requester returns and asks for additional functionality. That gets noted and acted upon. This cycle continues until the requester feels satisfied and the application is approved and moved into production.
So far, in the development phase we can see from this example that the project is uncontrolled forcing the developer to be in a reactive vs. proactive state. What can occur next is often expected without a PM process. The application goes into production and suddenly something is not working as expected. This could be caused by several factors. It was not fully tested before it went into production because there was no documentation to reference to create a test script. Or, the requester is looking for functionality that they did not ask for or forgot to ask for and there is no documentation to reference that identifies what did or did not take place. There could be other reasons but the outcome is the same, discouragement, disgruntlement, along with additional time and costs to complete the project.
Once again, in this example we see the project resources in a reactive state, uncontrolled by any formalities thus chaos exists. The reality of this example is the fact that the resources are not being effectively utilised and the corporation will pay for those additional costs financially and emotionally. Trust me, if the majority of your corporate resources are operating in this chaotic state, it will have a work-life balance drain on them. Additionally, the quality of the product is not managed effectively, thus the corporation will end up paying for that also. The productivity of the project resources is also at stake, and yes, there is a cost associated with that.
If we take this example and wrap a PM process around it we end up with different results. We would create and maintain solid and documented project requirements. Project requirements will be used to develop your future test methods, with the requirements fully documented, the information you need to test for in your application is already in your hands. The project manager could begin with the end in mind and work backwards to complete the project schedule. With software applications, incorporating the SDLC structure into the plan is good, but be sure to gather the business user(s) needs and requirements and get those into the plan as well.
At this stage, we have already improved the process, documentation can be referenced to develop the application and the same documentation can be used to create the test cases. Suddenly, it is realised that we need to add a function to the application that was not in the initial project scope, this is where process kicks in. This is commonly referred to as change control, used effectively, a change request is made and before it is acted upon it needs approval. Once approved, this change is documented as part of the project requirements, so that it can be developed but also tested in the application testing process. It is also added to the project plan and monitored accordingly. (Please note that I have not gone into the risk factor discussion here, that is the subject of a future article)
PM processes provide a structure of managing information needed for the successful completion of a project. When I say "successful completion" I am referring to the triple constraints of project management which are the project cost, schedule and scope which wrap around project quality. If the outcome of a project is not up to par with the quality objectives, no matter how well things went, the project could be categorised as a failure.
In my research I have learned that as an organisation implements a PM process or methodology, there are associated corporate REAL DOLLAR cost savings. For example, the median cost of a project can be reduced by up to 75% over an undocumented process. The project schedule can be reduced by close to 40%. The 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 organisation is diligent in the implementation of a sound project management process. As an organisation matures in the use of project management there are additional cost, time and quality savings.
Let's take a moment to put the above savings into the actual numbers. The studies indicate that if you use a project management process, that your $100,000 application could have been developed for $25,000. That is quite a substantial savings just on the budget, and you have $75,000 to spend on other initiatives. If a project schedule can be reduced by up to 40%, which means the 20 week project schedule can be reduced to 12 weeks. With this in mind, now you have money and time to work on other initiatives. Next is project resource utilisation, with up to a 75% savings, what took your resources 800 hours to accomplish now takes 200 hours to accomplish. Now you 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 may have been 20 product defects ends up to be 4 defects. You end up with additional time, money and resources with less product defects. What is going on in your enterprise?
We are in a time when enterprises look specifically to increase business efficiencies by streamlining processes. IT managers are asked to maximise a systems ROI and align Information Systems with the goals of the business. In order to effectively accomplish this, C-Level executives down the ranks to IT managers need to understand how processes such as project management and others, impact the overall cost of systems and applications.
In challenging economic times, corporations that have sound PM processes in place (in addition to other sound business processes) are capable of focusing their efforts on controlling corporate costs and increasing profits using traditional methods. Compare this to organisations that need to control costs and increase profits in addition to improving business performance, improving business information, improving security, improving efficiencies and improving service to customers, suppliers, partners and employees. The operational costs for the latter corporation will be staggering compared to the corporation that has sound processes in place. Without sound PM processes in place, while projects are developed in chaos, they may be completed by sheer heroics. There is a corporate cost to operating under this method, my recommendation is to know the difference and make the right decision.
In my next article, I will be discussing project management solutions that can help alleviate some of the pains that corporations can endure during a time of financial concerns. More information about me is available via Linkedin, feel free to look up William M. Thom - MISM, PMP.