When you start a process improvement project based on CMMI practices, you need a lot of advice. A good consultant is a must. The great www is also full of ideas, some good, some not so good.
🙂
Some advice I found extremely useful is related to process definition. One should keep process definition as simple as possible. Organizing the process documentation in a pyramid like hierarchy is the best.
No need to fill a hundred of pages to describe your process. Nobody will ever read them all. Better start with a high-level description of the process on 3-4 pages. A diagram of no more than 5-7 high-level activities will be helpful for everybody: team, management, auditors etc. Add inputs, outputs, resources,responsibilities and a short description of each activity.
If more detail is needed, move the detail to the next level:instructions. If possible, embed detailed instructions in the tools: templates, electronic forms, online help of the development platform etc. If you really want to write a detailed instruction manual, use graphics, pictures, metaphors. One image is worth 1000 words, ain’t it?
🙁
What bad advice did I find on the www?
One stupid advice was that if you have in your team a very good programmer but who doesn’t obey the established process, you should fire him/her. Now this is like killing the goose with golden eggs. A good programmer can make the difference between a nice software and a nightmare software. A good programmer is not so easy to find. It takes several years to make a good programmer.
So what’s to be done?
First of all, consider the fact that not all human is open to change.
One should discuss the process with the team. Maybe the process is at fault. Automate as much as possible. Embed measurement data collection in the daily routine. Microsoft Team Foundation Server is a good example.
If anything else fails, start negotiating. Explain to the team why some activities, less creative, more administrative are needed.Make sure you have a good case.
Ask the team some simple questions: Do they like working overtime for weeks and weeks? Postponing holidays? Wouldn’t it be nice for everybody if the path of a project can be predicted more accurately? How about creation – the best thing in programming.
Wouldn’t they like more time for creation and less for bug solving?
And so on. Negotiating with genius and artists is tough but this is what makes a SPI project interesting and helps your brain to stay young.
Emilia Dragne
BIS SPI Project Manager