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
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:
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: Rules of thumb 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.
Rules of thumb for developing processes- Lessons learned from the
trenches
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.
Overcommitment: An artist's tale
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) 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.
Book reviews
DePree, Max, "Leadership is an Art," Doubleday, New York,
NY, 1989.
©
1998 The Process Group