Process Improvement Starts with a Blank Page!

So anytime you’re doing something more than once, there is an opportunity to do it better every consecutive time. Over my career, I’ve worked in a number of different project teams; software teams, hardware teams, software/hardware teams, even a marketing team!

One thing that has been consistent about my experience in teams though, is that if you are trying to get many people to work efficiently on one project, you need a process. Now, I know there are those who don’t favor process, and I agree with them that a bad process is just as destructive as no process, but a good process, that’s a different story. And also, sometimes, there isn’t any process in place whatsoever, and I don’t mean there isn’t any processes in existence, it just that the team and project you’re working on hasn’t adopted one.

So where do you start? Well, I have some principles I’ve always used to guide me thinking.

First, start with a blank sheet of paper. I have a philosophy that by even having a blank sheet of paper, that represents your process, you’re already off to a good start, because you now have a process to improve on. But if you don’t even have a blank piece of paper, you haven’t got anything to improve on, so you’re doomed to keep starting from scratch and feeling your way through every project, painful ad-hoc step by painful ad-hoc step.

Second, think logically about the stages/phases of your process, and the functional groups involved. For example, let’s say your trying to build a new product, you can start simply by saying, what are the big steps we will go through as a team, and what are the functional roles that the team will play. This is important if you want to avoid having everyone involved in every part of the project. This kind of high contact leads to burnout and failure, as everyone is always on, even when they don’t need to be, and your project ends up looking like a rave party than a slow waltz. So an example process sheet would look like (I like to use Visio Cross Functional Flowcharts):

Next, you put a simple box in each intersection where a process activity needs to occur. Now, I never put more than a single box in an intersecting square. The purpose of the chart above is to highlight a work interaction between a functional team and a phase, you can drill down into the actual deliverables and steps later. So my process might look like this.

So for example, in the Requirements phase, the business team are responsible for building the customer requirements. To start with, you may not have any steps, so at the project kickoff, you would start by defining the steps for this project to satisfy that part of the process. Next time around though, you could look back at the last project and say, “Wow, out of the 3 things we did, the focus groups worked really well, so let’s add that to the best practices list for Customer Requirements tasks”. Again, it’s not about forcing people to follow anything more than the high level process, but you also want to capture the prior learning, and express it in a way where someone can look over the task list for a process stage and say, “This was used to get this outcome, and I think I need that outcome for my project, so I’ll use that task”, but also enable people to add new tasks to the catalog.

The next step is you have to have a basic communications plan. In too many projects, emails fly around between project members and other connected people, with everything from FYI’s to work items and change requests. It’s dangerous because the wrong people can affect the outcome of your project, and critical items get lost in the email explosion. Set up some basic email aliases for your project, at a basic level, have 3:

1. A basic project comms alias for general FYI comms

2. A change request alias where requests can be managed

3. An oversight/stakeholder alias where critical decisions that need stakeholder approval/review can be sent

You should also attach a contract to each alias, for example, for the oversight alias, you might say that all the people on that alias commit to responding to any email sent to that list within 24 hours. This way, the alias doesn’t just become an vacuum or black hole, and people don’t lose faith in the alias and start emailing people directly.

And finally, you should have a clear accountability matrix. This ensures that the right people are involved in the right parts of the process, and more importantly, the wrong people are not involved. You matrix should map to your functional groups from your process chart, and should follow a model such as OARPi (Owner, Approver, Reviewer, Participant, Informed). This way, everyone knows when they are involved, and in what capacity. And also, they know who is not involved, so they can filter those people from the process. It really improves the signal:noise ratio for a project.

And that’s pretty much it. Each time you runt he process for a project, take the time at the end of the project to reflect, then update the body of knowledge for the process, highlighting tasks that worked really well in a phase for a functional group, and also tasks that didn't’, and include enough information for the next person so they know what you were trying to achieve, and what the outcome was.

Process is good, process is your friend! :)

Technorati Tags: Stuff