The Hidden Costs of Application Development
This article will explore the hidden costs of application
development and how augmenting existing processes with FDD
can save significant time and money while providing flexibility
and accountability for customers, development teams and executives.
Are your development teams being asked to deliver too many
requirements in too little time? This article will introduce
the concept of “activity noise-level” as well as
examples of developer activities (“time stealers”) that
are generally not tracked within an organization that can
jeopardize the successful implementation of IT projects.
Learning to recognize, identify, and correct noise-level
activities can have a tremendous positive impact on the organization's
ability to deliver projects on time, within budget, with the
required feature set.
| Here are a few indicators that
the activity noise-level may be adversely affecting
your team. |
|
- Simple tasks take significantly longer to
do than expected or don't get finished.
- Tasks aren't completed because you are constantly
putting out fires, chasing down information,
and doing a lot of busy, unproductive work.
- The information needed for completing a task
resides in several areas.
- The next step in a process gets delayed because
notification that the task was completed is
missed, not sent, not expected. Or not everyone
on the notification list was notified.
- Tasks completed by one group are moved to
the next group and returned because something
simple was missing.
|
|
Let's take a simple example. How many times have you had
to stop what you were doing because the project sponsor or
another executive needed to know the status of a project and
he needed it in 15 minutes for a very important meeting? Sound
familiar?
You dropped whatever you were doing, went to your direct
reports, or worse, broke the reporting chain and went directly
to each developer to find out the status of their work. Let's
say your organization has five development team managers, and
each manager has five developers or a total of 30 people. Let's
imagine that in order to get the status, you take 10 minutes
for each person, to get up, walk down the hall, track them
down, corner them about the project status, and get them to
drop what they are doing to get it for you. Then your direct
reports have to do the same with each of their developers,
testers, etc.
That's 5-1/2 hours for a single project status request. If
status is requested once a week, for a six-month project, this
translates to a savings of 132 hours.
As a project manager, couldn't you find a more productive
use for an additional 132 hours? What if you're asked for
status two or three times a week?
| Ask yourself the following questions: |
|
- How many times in a week or two week period
have you been asked for status?
- How much time is your team spending recording
status?
- How often do your people tell you they are
almost done?
|
|
With a little planning and organizing, you may be able to
change the process or augment it with steps included in another
process. One example of this would be the use of aspects of
the agile process Feature Driven Development (FDD). Feature
Driven Development (FDD) focuses on small cycles, small deliverables
with user identifiable functionality and ongoing feedback.
One way FDD helps to reduce some of the activity noise level
is by using milestones to measure progress. Milestones are
nothing new, but the discipline applied to using milestones
in FDD makes a big difference. During the construction phase
of FDD, which is Design by Feature and Build by Feature, there
are a total of six milestones that mark progress on each feature.
The milestones are binary in nature. They are either complete
or not started. Remember, there are six milestones on each
feature, which is time-boxed to two weeks or less. This means
that the milestones are measuring small amounts of work and
there is no guesswork. All six milestones must be completed
before the feature is done. This makes the status reporting
very accurate and also provides a basis for predicting future
completions based on current performance.
Example: If you have 40 features to deliver in four weeks,
that breaks down to completing 10 features a week, or 20 features
every two weeks. If I just delivered 20 features but it took
four weeks to do it, what is the probability that I will be
able to complete the remaining 40 features in the allocated
time if nothing else changes?
In our status-reporting example, using features and milestones,
it becomes a relatively painless mechanical exercise to gather
the milestone information and roll it up to project management
and executive levels. This reduces the amount of time it takes
to get project status and also increases the accuracy of the
status report because the data is a more accurate representation
of the completed work. There aren't any 90% completed programs
or tasks that stay that way for six months!
What we have just demonstrated using a concept in FDD is
a key technique to reducing the activity noise-level in an
organization; Automating mundane, time consuming tasks
or making them a result of a value producing task.
All of this translates to a strong return on investment while
improving the way customers perceive your team's ability to
deliver.
Wouldn't it be nice to have a place where people could
go to find out the status of a given project without interrupting
your schedule?
For more perspectives,
click
here to view the white paper that this article is based
upon.
|
