Working in development is like that. Brilliant, creative people focused on a specific task, oblivious to everything else going on around them. As a configuration manager, your job is to support them, to keep the bigger picture in mind, and often to find better ways for them to work.  When find yourself tasked with making your development world a better place, there are things you can do to ensure the processes you develop are relevant, timely, and even appreciated.

The basic concepts of process development are easy. Process development is just figuring out how a team can work together efficiently to:

1. Get something accomplished
2. Learn from the project
3. Do it again.

Working in teams well means working with people well, and human nature has a big role to play in the success or failure of a project.

In fact, the primary mitigating factors to a project's success are related to attitudes and relationships.

• People and personality issues
• Life events
• Work conditions (too much work, not enough work, unfulfilling work)
• Business drivers
• Regulations
• Turn-over
• Ergonomics
• Technical limitations

Successful process implementation takes skill, especially in the areas of listening and diplomacy. Your team doesn't have the luxury of stopping their work and learning a new process. They have to continue working. Therefore, they take on more work in learning your process. Their roles are even less productive. You're making the situation worse before you're making it better.

Many tool vendors will say something to the effect of "No problem. Use our process. Use this tool. Everybody will be happy." 

Configuration Management tools and a canned process model can take away tedious organizational tasks, and can provide some structure to a project. But not much of that matters if your team members can't stand each other. 

Why do most CM solutions endorse just one tool and development process model? 

• It can be seductive to think that all you have to do is install their process model and your work woes go away.
• It can give you the impression that they are thought leaders in the industry, more steeped in process than you are. They know what's best for you. 
• That's what they have to sell to you.

The reality is that software development is done in many different ways and the process model needs to support your company's business drivers.

You can make a process model that specifically meets your company's requirements. The technical aspects of it are pretty easy. The human interaction side of it is challenging, but nothing out of a box is going to help you much with that.

So, how do you do it? Of course, you follow a process to make your process. A few years ago, I created a simple process called ACME.

The acronym ACME is a good way to remember the four objectives of process development:

• Automate where possible. (Workflow structure and support)
• Capture information. (Decision Support)
• Mitigate risk. (Risk Management)
• Evaluate your progress. (Continuous Improvement)

The ACME Process has five steps.

Understand the Business you are in.

Identify your company's business drivers. How does your company make money?  What benefit does your customer get from using your company? What's most important? Budget, Quality, Time to Market?

You need to know this because it makes a big difference in the processes you use. Companies with a high quality business driver invest in more requirements, design and test phases. A shorter time to market driver may require a rapid development prototyping process. Companies looking to cut costs will try to boost productivity

Document what currently happens and quantify the pain.

Everybody has natural processes. You tie your shoes the same way each time. Natural processes will expose you to what hurts, and expose the logic used to try to make it better.

As you talk about what hurts, expect lots of finger pointing. There is some truth in all of it. As humans, we're quick to think that every problem is an attitude problem.

Your customer doesn't care who screwed up. Don't be caught up in the blame game, and don't take sides. Gather as many requirements as possible. You're not going to fulfill them all (at least not right now), but this will help you make wise choices in the solution development phase.

Quantifying the pain is more difficult. You can do it in terms of productivity costs  (How many extra hours did it take for this project).  You can do it in terms of human resource turnover, or system up time, whatever is relevant to the problem at hand.  

Source the pain and develop the solution. 

What is the real cause of the pain? Is it a human resources problem? Does someone need more training?  Are you having problems with a tool? Or is the process inadequate? Usually it's a combination of things.  How are you going to fix the root issue?

Run through the ACME questions:

Automate - What can I automate that would save them time? Usually it's organizational tasks, like bug tracking, or issue management.

Capture Information - What information could we capture that would be useful for us?  Be very careful about the information you're gathering and make it as visible as possible. Going overboard here is the fastest way to ruin your chances at a successful process implementation.  

Mitigate Risk - What are our risks and how can we handle them?  Look for behavioral risks too. Morale and motivation are key factors in on-time, successful projects.

Evaluate your Progress - What's working, what isn't working and where can we improve? Continuously evaluate and shape your process. 

Recommend several solutions and implement one quick win. Then roll out the rest.

If you can, having several solutions provides an opportunity for someone to make a choice about what to do.  One of the best ways to gain visibility and support is to get a real quick win. It has to be quick, simple and effective. Sometimes a simple bug tracking worksheet will work.

Roll out the rest of the solution on a project-by-project basis. Don't overwhelm yourself by rolling it out to everybody at once. People need a lot of handholding while you're changing how they work, and the later projects will benefit from your earlier implementations. 

Evaluate

Evaluate as you roll it out. Evaluate it afterwards. Seek advice. Your opinion doesn't matter nearly as much as the people you're supporting do.

It's not easy, but is rewarding. You're doing noble work, this diplomatic art of getting people to do their jobs in ways that are helpful to the team, the company and the customer.  If you use the ACME process to make your own process, and you have any suggestions, please drop me a line at bridget.Pilloud@merant.com

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment