Driving Process Improvement as a Project Manager

The primary delay in companies today, are processes that don't align with the work being done. This happens for a variety of reasons from the process being out of date to well meaning poorly implemented changes to a process.

As a project manager, we see the effects of these ineffective, inefficient processes daily. We see these things when our projects take longer, we have dependencies where the work waits on the process or things are delayed for an artificially imposed dependency. To improve our chances of success and the success of other projects in the company, we should be identifying and working to resolve these process issues as they are identified and outside of the flow of the project.

If there is not a process improvement team inside your organization, the PMO is a great a place for this responsibility. If you work in an organization that does not have a formal PMO, I would suggest taking the initiative to spin up a pet process improvement project led by the project manager. This should be something that goes through a formal SDLC with requirements gathering, prototyping, development, and analysis after the change. Many people will talk about the DMAIC process most well know for its place in Six Sigma which is a great process, but may be overkill depending on the size of the process you are trying to improve and the maturity of your organization. As such, unless you have a formal process improvement team, committee, or initiative I recommend the approach below.

If you don't already have some areas that need improvement, start with looking at your current processes.I have found the three areas below to typically be the areas with the largest opportunity for improvement. When evaluating them, look for places that process is driving the work rather than work driving the process. For example, some organizations require code review before the code goes to testing. This process typically takes days to get on the schedule and results in the code siting in a queue and waiting since it had to be done before the code review could be scheduled. Could you adjust the process so that code review can be requested or scheduled in the future? Could we change the code review to not be a stop and wait? Perhaps the code could continue forward to the test environment and code review could happen later (this may produce technical debt).

1. Testing
1. Is your testing automated? 
2. How do you regression test?
3. Do you have a full test environment? 
4. Who executes your testing?
2. Release Management
1. How do you migration code from one environment to the next?
2. Who is responsible for production releases?
3. What is an acceptable level of bugs released to production?
4. Are there established release windows?
3. Requirements Gathering
1. How detailed do you require your requirements?
2. Do you require a phase gate before leaving requirements gathering?
3. What is your system or approach for requirement changes?

Unless you have the support of your organization and management team, I suggest that you select the single biggest value (most time saved) and focus on that for your first process improvement and only work on one at a time.

There are entire process improvement methodologies out there that you can use to execute process improvement (Six Sigma, Lean, Business Process Improvement, etc) but here is a simple step by step for your basic process improvement:

1. Select process for improvement and create a step by step process map (example)
2. Schedule a review meeting with the concerned parties and review the "as-is" process
1. Remember that some of these people may of had a role in the creation of the now out dated process, so be nice!
3. Confirm the process as accurate and then discuss each step and what is the value of the step
1. Really drive to understand: What value does that step brings to the process? 
2. Pay close attention to why each step happens in that order. 
4. Looking at the process from delivery to the down stream process as your goal, identify how you can make that happen faster. 
1. The items such as documentation are still valid, but why can't they occur after the product or item is delivered to the downstream process? 
5. Work with the team of concerned parties to re-organize the work and remove any tasks possible.
1. For example, do you have to stop and wait for an approval or can the work continue while the approval is happening? 
6. Test small scale, with a single project for a few weeks.
7. ITERATE! Don't be afraid to carve to much off and realize that you need to add some back. 
8. Once the team is comfortable with the new process, make sure it is well communicated to everyone otherwise adoption will fail.