Empowering IT Projects I. Introduction A. Philosophy The history
of programming has had many milestones. The '60s saw the beginnings
of the concepts of "Modular Programming;" In the '70s into
the '80s we taught Structured Design and Programming concepts; In the
mid to late '80s prototyping began to take hold. Other "hot topics"
included testing concepts, object-oriented programming, and quality. I believe
IT projects will not be fully effective until there is a stronger linkage
between techniques for project management, structured methodologies
and testing. What follows is based on a course I am currently teaching
and which is at the cutting edge of my latest thinking of how to influence
and empower project managers to produce better products which more closely
meet the users' needs. Whether
you are a project manager, programmer, programmer analyst or systems
analyst your ultimate goal is to provide your customers with a product
which comes as close as possible to meeting their needs at the least
possible cost in the least amount of time with the highest degree of
inherent quality. This said, it is particularly disturbing to see so many systems produced
which fail to meet the most minimal set of these goals. B. An Example of the Problem A company
which I'll call VCT (the name's been changed but the example is, sadly,
very real) has offices worldwide. In the late '60s VCT wanted to create
a major accounting system to handle all accounts in all countries throughout
the world. By the mid '70s , after some $100
million in direct and indirect expense the project had to be abandoned.
The product could not be made to meet the user's needs. In the mid-'80s
the same company launched a project to have a common set of mainframe
software for all worldwide locations; after several years and the expediture
of millions it was abandoned. Recently, their latest venture was abandoned.
Something's wrong! If this
was simply an extreme example of one company's folly it would be sad.
But companies daily create systems which their users don't want, can't
use and which if used will cause business to suffer. When I've examined
the projects which produced these systems I find a common cord is woven
throughout-- these are very complex projects in which users are not
involved in all phases of the project to an extent which assures a product
which will meet the user's needs. Simply put, the commonality is: • Complexity. • Inadequacy of User Involvement. • Poor and Incomplete Measurement and Testing. This article
looks at an approach which I call Evolutionary Project Management in
which I combine the concepts of others into a cohesive approach which
can be used with the techniques
already used by your organization. C. The Current Situation 1. Positive Attributes of IT Organizations I have found
the programming staffs, in many organizations, to have very open communication
between their members. When interviewed, members are often upbeat and
positive when discussing the atmosphere at their company. Looking at
one another's code tends to be a fairly common activity. The seventies
have made an impact! In smaller
organizations, many of the staff have a solid
understanding of the business side so they are able to effectively interface
with users and these individuals generally understand the users' needs
quite well. There appears
to be a willingness to learn from the work of others. There is a willingness
to build upon the work of others. 2. Negative Attributes of DP Organizations When I talk
with programming staffs I often focus on their project life cycle. One
way I use the information on project life cycle is to determine how
much interaction there is with their users. The latest studies show
that key to producing solutions which meet users' needs is for there
to be constant contact with the user throughout the life cycle. Additionally
projects developed using the "Evolutionary Model" are
much more likely to produce results on-time, within budget and which
meet user requirements. In most
organizations feedback to users (e.g. "is this what you need?")
could be better and more frequent. There could
be a greater emphasis on quality. The IT staffs
needs better skills in identifying user requirements. This means not
only defining the functional goals but also the amount of resources
required as well as the quality aspects of these functional goals (e.g.
for an inventory system run once every six months, computer usage and
time resources are probably not important, but the system better work). Programmers
also need better design skills. Better designed programs will tend to
be less "buggy" and more
likely to be able to be successfully tested (more likely to be able
to find bugs). I find that programmers still start coding too soon.
They need to do more upfront design and the project managers need to
see that the projects are planned to allow for the upfront design. Testing
in many organizations is still seen as a negative activity. Testing
skills must be strongly enhanced and more effectively integrated into
the project metrics. 3. The Typical IT Organization While your
organization probably has a capable and willing staff, you are being
hurt by their lack of attention to their formal skills. But better algorithm
creation and testing skills will not solve the problems by themselves.
Programmers need to have clearer goals to work towards and project managers
must help develop these goals. By this I mean that the project must
be able to be stated in goal-oriented statements which can be measured
in terms of functionality as well as resource and quality aspects. And
the resultant programs need to be better tested. D. My Bias Perhaps
you'd better know a little about me. While having been part of Data
Processing world since the late '60s, I have been primarily a trainer
since '75. My particular interest has been teaching individuals to produce
more effective applications. In this article I'm focusing on project
managers but if you have some other job don't stop reading. The approach
can be applied by anyone. II. IT Projects A. Introduction I have often
been at a loss to understand how we can have so many really good programmers
and yet have so many bad systems. At first blush it might seem that
if the user's needs are understood by the project team and if the team
uses all of the latest and greatest techniques a quality product should
result. Clearly this doesn't happen nearly often enough. Lets look
at some typical project scenarios. Projects
From Hell Tell me
these aren't familiar. You're given an assignment to create a program
to produce some reports. It seems simple and yet when completed either
the user wants "enhancements" or the reports aren't even used. You had a project to produce
a new system. You'd met with the user. You both "understood" what was needed.
Every time you now try to turn over the system the user says it just
doesn't work. Yet it tests correctly. You recognize a need and
explain it to the user. The user won't hear of it. The user would rather
use the old antiquated
system than the new system with all the bells and whistles. Unpleasant
Reality 1 Users can't
possibly know what they want in the same way programmer
know it. They are users and programmers are not. There is no
way to eliminate this problem. Programmer simply see
things from different perspectives. We all seem to have a tendency to
fight this simple reality. This doesn't mean programmers can't ever
produce programs which meet the user's needs. Programmers can, but not
the traditional way of doing things. Unpleasant
Reality 2 There is
a very small amount of complexity anyone can deal with. Every time you
try to deal with too much complexity you fail. This failure might not
be so bad if you'd only really believe in the limits of complexity which
this failure teaches you. Unpleasant
Reality 3 Users would
rather be unproductive and use an old out-of-date system rather than
have the pain of dealing with a new system even if the new system is
"better." F. Project Management Life Cycles Ever since
there have been projects people have been trying to find a model which
expresses the project life cycle. There are Waterfall models; Whirlpool
Models; Spiral Models, etc. They have been trying to explain the life
cycle so they can finally make projects succeed. A successful project
is defined by these people as one which is on-time, on-budget and does
what the user wants. Unpleasant
Reality 4 No model
fully expresses or can express how people manage projects. Models are
a nice attempt but projects are filled with the unforseen
and nothing works like the model. Unpleasant
Reality 5 It may take
longer and cost more money to do it right. For years we have said that
its cheaper to do it right than to do it wrong and continually
fix it. I see many systems which after they are completed are never
revised even though they are not right. So doing it right may cost in
terms of time and money. Unpleasant
Reality 6 Our notion
of what makes a successful project is wrong. Projects are not successful
if they only are on-budget, on-time and do what the user wanted. They
are only successful if they also do what the user needs. G. The Quality Hot Button In recent
years everyone from Boeing to U. S. West has been pushing the quality
button. Books abound, corporate quality programs are taking off everywhere.
Ford says "Quality is Job 1." Meineke
Mufflers says "Nothing is unimportant." Yet quality issues
are much more slowly entering the IT community. And even in companies
where quality issues are hot, quality systems are not being regularly
produced. The company I previously called "VCT" thinks of
themselves as a company which stands for quality. Unpleasant
Reality 7 We are not
yet able to produce quality IT systems with any regularity. We find
it too difficult and time consuming so we settle for almost right. Many
system enhancements are simply attempts to finally make it right. Unpleasant
Reality 8 Implementing
quality is only difficult because we don't know where and how to begin
and how to end. By the time a programmer receives a specification failure
has been built-in because the project's goals are usually unclear and
unmeasureable. Beginning with measureable
goals and ending when those goals are met is a good beginning and end. Unpleasant
Reality 9 When the
user isn't happy the system can't have quality. Much has been written
about producing systems the user wants. But if the system the user wants
isn't what the user needs the system can't be called a quality product. H. Complexity Nothing
is more important than our lack of ability to deal with complexity.
The trials of NASA should teach us this.
Virtually every instructor of programming mentions that we have
difficulty dealing with more than three to seven things at one time
yet we still are not recognizing complexity for the problem it is. Unpleasant
Reality 10 Inability
to deal with complexity is the single most important problem facing
IT today. Most system failures can be traced back to complexity. We
have forgotton the old KISS principle if we ever really
believed it. Complexity
is such a problem that Unpleasant Realities 1 through 9 are
extremely pleasant compared to number 10. I. Project Life Cycle in Your Organization Every organization
has a project life cycle comprised of a series of phases. A typical
life cycle might look something like this. I could
point out obvious flaws like the documentation being done at the end.
But there is a greater issue which I'll get to in a moment. Before I
do, I suggest you get (or draw) a copy of your project management life
cycle so that you can refer to it. Looking
at this diagram I shudder. Does the user really make a request a then
allow us to go off to do our thing coming back to the user only at the
end of the project? Not likely. So, what is the answer? Evolutionary Project Management We believe
that traditional project management models do a disservice to consultants
as well as their clients. In the mid to late 1980's service quality,
the quality of service consultants provide their client (internal or
external), became a central issue. More and more companies have issued
positions and programs related to quality. In our field, one way this
has represented itself, is with the development of what has been called
the Evolutionary Model. What
is Evolutionary Delivery? The evolutionary
model illustrates the belief that the best way to implement a project
is by implementing many small phases with continually adjusted goals.
It has evolved from the concept of prototyping but may easily be used
in situations where prototyping does not apply. A prototype is usually
defined as a fully functional, full-scale version of the final product. The evolutionary
model is based on the following three-step principal:
1.
Deliver something to a real end-user.
2.
Measure the added-value to the user in all critical dimensions.
3.
Adjust both design and objectives based on observed realities. © 2002 Performance |