Vol. 5, No.1 March 1998

Out Of The Box

If you facilitate teams, whether conducting problem-solving sessions or deploying a new risk process, the team members might often hit a problem that seems unsolvable. In this situation, experiment with the following questions to help the team members with their mental block:

Q1. What would you do if you knew exactly what to do? That is, just pretend that you knew exactly how to fix it. What actions would you take?

This question sounds strange, but it is very effective. Keep a straight face when you ask it. The slightest giggle will break their concentration. If you ask them to imagine themselves, for only a few minutes, as being completely able to fix the problem and then list out the actions they would take, ideas will come forth that are very practical.

Q2. Whom do you know who could, without question, fix the problem; maybe a world leader that you admire. What would they do? Let's start with Norm Schwarzkopf!

When one imagines a totally capable person with the problem, it is much easier to think of solutions. For example, if the problem is getting management commitment for a process idea, ask "What would Mahatma Gandhi do in this situation?". The team might respond:

"Well, if he were in charge he would:

• Ask the manager what his/her goals are to arrive at mutually agreeable options.
• Explain what agreement is being sought from the manager in non-offensive terms.
• Focus on win-win. Neither side would lose."

Try it; practice it; facilitate out of the box!

--- Neil Potter

Top of newsletter

by MARY SAKRY

Once your process improvement program has been running for a while, it is wise to study how well things have been going and determine if your approach needs refinement.

Finding out what happened

If you want to learn how well things are going, you need to talk to the people who are being asked to change their behaviors and adopt new practices. This might include managers, developers, SQA and testers. An effective way to do this is by interviewing individuals or using discussion groups. When you use group interviews, be careful to construct the groups to allow free flow of information. This means you need to group people who are willing to be frank and candid in front of each other.

Be sure that the interviews are run by a good facilitator. You may need someone other than those in charge of process improvement to conduct the interviews. Brainstorming helps candor by allowing people to say anything they want without evaluation or interruption.

What to ask:

• "What has gone well?"

Study the positive comments, looking for ideas you can reuse. For example, if the format of a current class is very popular, try to use the same format for other classes. If an on-line web site works well, try putting other documents on-line.

• "What did not work well?"
• "What barriers or root causes exist, preventing useful improvement?"
• "What could be done differently in the future to make process improvement better serve your needs?"

You may hear comments with which you disagree. If you are the change agent and the discussion group is your customer, listen or perish! If the comments are divided equally, positive and negative, you may have it about right. (For example, 50% said that a specific process improvement idea was the right length and 50% said that it was too short.)

Set priorities and address the issues

Maybe you are not spending enough time on institutionalization. That is, you spend too much time in meetings and writing processes, but not enough hands-on coaching for the adoption of new practices. Or maybe it is just the reverse; perhaps your processes have too little detail to be useful, and need rewriting.

Sometimes there is too little incentive for people to change. Maybe you need more management support to encourage people to adopt new behaviors. One organization that we work with offers a $30K award for the best improvement of the year.

Consider what you have been doing and examine the opposite

• If your processes are long and wordy, make them more succinct; if you never leave your closet to help people improve, get out there and consult; if you mandated a process and it was ignored, don't mandate, but rather build a demonstration to show how the technique helps.
• If you were rushing to SEI Level 3, but didn't complete Level 2 yet, go fill in the gaps.
• If you were too focused on a particular SEI level, go back and make sure you are actually making things better. Throw out what is overkill or rewrite the useless.
• If your SEPG was composed of only managers, try using practitioners or a mix of both.
• If you run all of your improvement teams the same way, try letting them use different approaches and compare the results.

When you determine what went well and what did not, share your results with the whole organization. Thank them for their help and let them know what you plan to change and why. Don't ignore the feedback. Make sure they know that they were heard and that you are making the changes to better meet their needs.

Top of newsletter

Risk-based Process Tailoring

by NEIL POTTER

As processes become more detailed, it is likely that not all process steps will be needed for all situations. This is particularly true for development life cycle process documents that go into detail about the activities within each major life cycle phase. In order to avoid becoming overwhelmed by the process tasks described, tailoring guidelines are needed. They help the reader determine the activities required for different project situations.

For example, suppose the process tasks for developing a project estimate were:

Estimation Process Develop a Work Breakdown Structure (WBS) for the software requirements Purpose: To break down the work into smaller elements and group them by outcome. Conduct a team estimation method (for example Wideband Delphi) on the WBS Purpose: To get team input in a controlled fashion and develop a detailed task list, set of assumptions, and estimates for a WBS, or component of a WBS. Use the historical database to verify the estimate for each task Purpose: To search the organization's historical data to see if a similar task (or group of tasks) exists so that previous experience can be used.

Executing all these process steps may be appropriate when the project estimate is critical. In such circumstances, any error may lead to a loss in income or severe penalty charges for late delivery. For other projects, performing this level of estimation for every component of a project may not be necessary.

Tailoring guidelines help the reader determine what steps to omit and to understand the corresponding risk. In the example below, tailoring information is described by three additional sections for step 3: Tailoring guideline, Risk if omitted, and Minimum Requirement.

Estimation Process (Step 3 with tailoring guidelines) Use the historical database to verify the estimate for each task Purpose: To search the organization's historical data to see if a similar task (or group of tasks) exists so that previous experience can be used. Tailoring guideline: This step should be performed whenever applicable data exists. It can be discarded when a new language or technology is being used. Risk if omitted: Failure to use the database could result in significant oversight about schedule estimates, and could lead to a loss in revenue. Minimum requirement: Data that exists, but is not considered applicable for the current estimate, must be reviewed with one other manager to verify non-applicability.

Below is a different example of process tailoring for a software testing process. The table contains a list of test tasks that a project may read in a default process description. Tailoring considers the risk or impact of not performing that activity.

From the table below, one can see the final tailored process (the decision column) and also evaluate the overall risks of omitting some of the process steps. In this example, the project risks related to tailoring the process are:

• All scenarios of code execution are not tested.
• 40% of the code may not be verified to execute correctly. Later conditions may cause untested code to be executed.
• Product may fail during heavy customer usage and with large databases (greater than 88MB).

As experience is gained regarding the benefits and problems of tailoring process steps, lessons learned can be factored into the tailoring risk of omission column.

The Deadline

Tom DeMarco's playful novel is riddled with good ideas and thought-provoking assertions. This is the story of Webster Tompkins, who has been kidnapped to Moravia to run software projects. Reading this novel makes for good light reading by providing chuckles and little gems of wisdom.

The book's strength is its blatant acceptance that running projects well involves many issues, such as how people interact, jell as teams and solve problems.

Here are some random items stolen from Webster's journal:

• "Manage projects by managing their risks."
• "Productivity improvement comes from long-term investment. Anything that promises immediate term results is likely to be snake oil."
• "No matter how serious the threat, the work still won't get done on time if the time originally allocated for it was not sufficient."
• "You can't get people to do anything different without caring for them and about them. To get them to change, you have to understand (appreciate) where they're coming from and why."
• "When there are multiple parties to a development effort, there are bound to be conflicting interests. Conflict deserves respect. Conflict is not a sign of unprofessional behavior. Negotiation is hard, mediation is easy."

This is a creative tale full of good ideas for contemplation, with dashes of satire to keep you entertained as you see some of your favorite industry icons (and maybe yourself or your boss) receive a little poke from Mr. DeMarco, all in good spirit.

DeMarco, Tom. 1997. The Deadline. New York: Dorset House.

--- Mary Sakry

Top of newsletter