Market window: Myth or fact?

During our travels over the past four years, Mary and I have heard many issues and questions related to software process improvement. One of the common issues is meeting the 'market window.' It is true that customers and markets have needs, and one of these needs is a delivery date. If your organization is overly market-driven, consider asking the following questions:

Where did the market window come from? Specifically, who said what?

Was it a date from the marketing department, engineering department or a customer?

Was the market window based on our guess of the competition's delivery date?

Exactly what are the expectations for this date? Is a user manual expected, all features, specific features?

Given that the market date is fixed, what can we do well and what should slip into the next window?

Often we start asking these questions and uncover miscommunication that caused the organization to rush beyond a reasonable level.

Working smarter and faster is good. Meeting customer deadlines is good, but rushing based upon false or ambiguous information does not ensure a good environment for success.

--- Neil Potter

Top of newsletter

Rules of thumb for developing processes

- Lessons learned from the trenches

by MARY SAKRY

How do you start writing a process? Look to your process assessment and the needs identified at that time. Often organizations find it useful to start with some simple processes that address the key problem areas identified during their assessment. These are usually related to project planning, estimation, configuration management, software quality assurance, requirements analysis and sub-contractor management. It is important that the processes chosen help solve key problems.

Often, as part of working on the project planning problem, organizations decide they need a process for the development life cycle. Resist the temptation to develop anything other than a high-level overview process in the beginning. It is very easy to get carried away and create a large document that can overwhelm the organization. If you begin with an overview for the whole life cycle, try to limit the process to the key tasks and keep it to two pages. If you set a two-page limit, then you will eliminate the level of detail that is only appropriate later (e.g., level 3 organizations).

Evolve your processes

The SEI maturity framework advocates process management, which causes the evolution of useful processes and standards over a long period of time, i.e., continuous process improvement, not sudden standard introduction.

Increasing levels of standards and processes are introduced when needed and most appropriate for the organization.

Anatomy of a well written process

A process should be short, to the point, easy to read and useful. It should tell what is to be accomplished, how you know when the task(s) are complete, and what the results should be.

Often people include at least the following:

Entry Criteria - states the minimum requirements to begin the process

Process Tasks - states the tasks to be completed

Process Verification - states how to verify that the tasks have been complete in the manner that they should have been, with the desired results

Exit Criteria - states the minimum requirements to leave or exit the process

 

Others add information such as:

 

Inputs - states the products needed to perform the tasks

Outputs or Artifacts - states the deliverable work products of the tasks

Responsible Parties - states the people responsible for the tasks

Participating Parties - states the people who participate in the tasks

References - states experts, books, and classes to help better understand the tasks

 

Charts, diagrams, and even datalflow type pictures may be useful in describing processes.

Rules of thumb

• Create processes and procedures as appropriate for the problems being addressed. Do not be too quick to write large documents. Focus on getting smaller processes used and refined.
  
• Standards and processes are most effective when they come from the people involved. One-page, frequently updated and evolving ones are the best.
  
• Provide automation for well understood problems. Do not jump too quickly to an apparent easy solution (tools and templates).
  

Life cycle processes

If your organization is at the initial maturity level, don't write a life cycle process that is very thick and detailed. Write a process that contains the handful of tasks to enable the organization to go from the beginning of a project (A) to the end (B). Concentrate on what needs to be done without giving too many details on how it is to be accomplished.

Once an organization can go from point A to B in a repeatable and predictable fashion, add further detail. Your first processes should probably be at the project level, and as the organization matures you will discover the important tasks and process step that should be global.

As you move to more global processes, you must ensure that there is plenty of opportunity for tailoring to meet specific project-level needs. At SEI level 1, the schedule component of the project plan is the software development process.

In summary

Don't mistake documentation for progress! Keep your processes succinct and evolving. Start with simple processes, then over time add more detail. Begin locally with projects and then move toward organization-wide, tailorable processes. Remember, you must be solving real problems. A process should be a guide to help people do their jobs.

Top of newsletter

Overcommitment: An artist's tale

by NEIL POTTER

As a young girl growing up in Vienna, Frieda always knew she would compose and play the violin. By the age of 22 she had become an accomplished player and decided to found an orchestra.

She started by contacting three violinists that she knew from college. Two months later, Frieda got her first call for a concert. After several concerts, the orchestra was asked to add more variety to its music. Although Vienna was strongly drawn to music for violin, brass was becoming popular. Frieda employed two trumpets, a trombone and a French horn to meet this need.

As management of the orchestra increasingly intruded on her time for composing, Frieda decided to employ Liesl, a local businessperson. Liesl arranged concert dates, organized logistics and secured future business.

Liesl had recently attended the Nice Film Festival and had met many film directors in need of original film scores. She committed the orchestra to four films -- two romantic comedies, a Shakespeare remake and a film adaptation from a book about a New Orleans jazz musician. Excited, Liesl returned to the orchestra and started to tell the musicians how much work she had generated. While Liesl was in France, Frieda promised record producer two Christmas albums.

The members of the orchestra worked longer and longer hours. As they composed more, they practiced less. With no time to practice, any temporary stand-ins had to learn the music on stage. The volume of work caused the compositions to become rushed. Errors had to be removed during expensive time at the recording studio. Music performed live was done as the ink dried. Audiences grew disenchanted with the mistakes and melodies that went nowhere.

Liesl continued to chase down new contracts. Every day the musicians had a different set of priorities. They were frustrated and exhausted. Customers were clamoring for scores, soundtracks and albums that were behind schedule.

After much soul-searching, Frieda decided that if they had been a little more selective about the work they had taken on, realized the time required to complete each successfully, and planned to that capability, they may have finished fewer projects --but with more success. She also realized that both she and Liesl had been simultaneously committing the orchestra to writing and performing contracts. Surely it would have been better to sit down and talk about the commitments with each other before agreeing with each customer.

Frieda went to Liesl and drew her into a discussion of their problems. Liesl had been frustrated at the orchestra's inability to work fast enough. She was tired of feeling like a fool, continually apologizing to clients for missed deadlines and discords on the albums. Both agreed they would first determine the various kinds of contracts they were working on and how long each took to do well. This would help them schedule future work so that they were not overcommitted.

Frieda asked Liesl to call each current client to reconfirm delivery dates and to see if any of them could be delayed. Liesl relented, since she had noticed that many clients didn't use the music for at least two weeks after delivery, anyway.

Frieda asked that the musicians be involved in future discussions of contracts. The musicians would then have a better chance of setting commitments that both met the customer's expectations and the capability of the musicians.

Liesl called a meeting with the musicians to explain the discussions she had had with Frieda. She asked for ideas on how the group might be able to avoid another crisis. The Trombonist, Kurt, volunteered that if they were aware of the work before a commitment was made, then they could realistically appraise work estimates. Liesl said that she was willing to try his suggestion for six months.

When the trial period was over, Liesl expressed concern that they had turned down several contracts but admitted that the contracts they had agreed to were all done well, to the extent that the same clients expressed interest in other projects. The musicians felt as if they were being respected for their talents. They were now spending more time on new work rather than correcting poorly written pieces.

To Liesl's surprise, the customers noticed the improved writing and performance. She had previously assumed that music was music, a musician was musician, and an album was an album.

Top of newsletter

Book reviews

Yourdon, E., "The Decline and Fall of the American Programmer," Yourdon Press, 1992.

"The Decline and Fall of the American Programmer" targets the domestic software engineering industry. Yourdon elaborates on the deficiencies of U.S. software development organizations and warns of the loss of this market to other countries such as Japan. Also discussed are issues of development teams, silverbullet methodologies and techniques. (Summary by David. W. Walker, Abbott Laboratories, walkerdw@hydrogen.abbott.com)


DePree, Max, "Leadership is an Art," Doubleday, New York, NY, 1989.

This book provides us with a unique understanding of leadership. It is a good book for all managers and process improvement people, one of those enjoyable little books that you hate to put down. It is easy but powerful reading, packed with the philosophy and intention required in providing good, solid leadership in a value-based organization.

The author focuses on how we treat people so that good things will happen for them and the company. He expounds on the wisdom that the best leaders are servants to those who follow.

Top of newsletter