The Project Proposal Process
By Wes Gardner
Imagine you are a custom
homebuilder with a strong reputation for doing quality work and a new
prospective homebuyer comes to visit.
The meeting starts out well and eventually the homebuyer asks you about
cost. In other words, the buyer says he
has put this project out for “bid” and you are one of the few with whom he is
talking. Of course, as a homebuilder
you would ask about a design (blueprint) from a paid professional architect on
which to base the bid. The buyer, in
turn, explains that he has not hired an architect or spent any money on
professionals, and hands you two pages of sketches he had done with very brief
one page description of what he wants.
Based on this information
you try to explain as tactfully as you can, since the homebuyer appears new to
this process, that there is no way to make an accurate bid on this limited
amount of information. You recommend to
the prospective buyer that if he is really serious about this project he should
get an independent architect or work with an architect within your own firm. After all, the design has to be done sooner
or later. You are a professional and
you cannot make an informed estimate without a design, and though you are
willing to provide an estimate for free, a design is another matter.
After this exchange, the
buyer explains to you that he understands what you are saying, but he cannot
afford an architect and would like a free design and proposal … if
possible. The meeting concludes with
you wishing the potential homebuyer the best of luck with this curious way of
getting bids.
In the software development
business there is usually no equivalent of architecture or engineering plans on
which to base estimates; and this often translates to too many guesses by less
reputable or experienced software consulting firms in an effort to get
business. Due to this dearth of
information, requiring us to usually serve as architect, engineer, and builder,
Chenault Systems offers its services for the design phase, which needs to be
done anyway. This serves as a great
qualifier to determine if the prospective client is really serious about doing
a project (and doing a good job).
We try to explain what
Chenault Systems has to offer, presenting our group as a management consulting
firm specializing in information technology.
Management consultants are really business physicians, keeping business
processes healthy. Sometimes the
process is beyond preventative medicine and needs a technology cure right
away. Sometimes it needs explorative
surgery to find out what is wrong, which is difficult to estimate in time and
cost. However, unlike the medical field,
a reasonably definite up-front estimate is normally paramount.
Medical doctors are rarely
pressed for cost estimates because often the bill will be paid by a third party
such as an insurance company or the government (which completely ruins the concept
of market forces maintaining efficiency and drives up costs) making the patient
less cost conscious. Doctors are also
dealing with human lives, which cannot be translated into a price. However, in our business of consulting and
software development, prospective clients expect some kind of estimate even if
there is little information on which it is based.
After
working with close to seventy organizations over the last eleven years, we know
that some form of up-front analysis is needed before an estimate is made. Otherwise, the result could be a thoroughly
flawed process from the outset.
Therefore, we have evolved into an independent firm, entailing the
following procedure for projects:
1.
Understand
the business objectives the client has for changing or enhancing the
system processes.
2.
Determine
up front if the client knows there will be a return on investment for system
enhancement and is willing to spend the time and capital to get this return.
3.
No
proposal or accurate estimates can be made unless there is a detailed study of
the process design. This
involves all the plans and alternatives for meeting the business objectives and
processes. The end result is a document
with specifications that could be used to get several bids from other
consulting firms. We have found that
serious clients are willing to commit to the cost of a 1-3 week review to
achieve a good design and a good estimate.
This is a good first effort from a cost point of view because a design,
as previously mentioned, must to be done anyway. Without the up-front design, the estimates would only be a sales
guess and nothing more. The process
design involves members of the client organization and the consulting firm to
make sure the business objectives are met.
Once the design is completed, both organizations have experience in
working together. In addition, if the
time estimates turn out to be inaccurate, then both parties understand
why. Process design is something that
is both planned and evolutionary.
4.
Once
the process design is complete, the tools or applications to accomplish
the process are evaluated. Make-or-buy
decisions take place. This may result
in the evaluation of software packages that can be purchased, the necessity to
custom build a system, or a combination of both. Sometimes existing systems are enhanced or re-written.
5.
The
infrastructure must be evaluated to match the above applications. The infrastructure consists of the
supporting computer hardware, operating systems, networks, storage capacity,
backup, and external communications, such as Internet connections.
These
steps encompass what Chenault Systems uses for the implementation process to
for major projects. Major projects are
defined as those projects that have a high impact to the client organization in
terms of cost savings or implementation cost.
Smaller projects can use subsets of the above four steps.
Project Management and Communication
By Tom Chenault
Managing a
systems project is never easy.
Direction, mission, people resources, financing, time and technology can
all be there, but the project can still fail if there is not sufficient
communication and organization. This
applies to any project, not just software development.
To borrow
a story from the book “The Mythical Man-Month”, by Frederick Brooks, we can go
back to the first historically recorded large construction project of mankind,
the Tower of Babel.
There was
a clear (a little under estimated, but straightforward) mission to build a
tower to reach heaven. With the
exception of God, which later proved to be a problem, it was a politically
popular idea. There was plenty of
manpower in terms of involuntary local laborers – with the additional benefit
of not having to worry about payroll deductions, workman’s compensation or
health insurance. There were plenty of
materials – clay and asphalt were abundant in the region. There was no time limitation or deadline –
they literally had all the time in the world.
The pyramidal design was good.
Masonry construction was well understood. The project started at an excellent pace.
God, who
should have been consulted in the first place, intervened and rendered
different languages (babble) to the different groups building the tower. Lack of communication caused a lack of
coordination. Arguments and fights
broke out. Distrust arose between
different groups, along with the usual blame games and politics. The project was abandoned.
The first
engineering project of all time was a failure – not because of economic
considerations, technical limitations, or a changing political climate, but
because of poor communication. Poor
communication will kill a project. In
the end, that’s exactly what happened; the Tower of Babel failed because the
leaders were unable to talk understandably to each other.
Large
software projects have the same issues.
A design and good analysis are key ingredients to a successful project;
however, communication is a must. A
plan showing how individuals and groups will coordinate with each other through
formal and informal meetings is needed.
Regularly scheduled meetings are necessary, with the understanding that
everyone will be on time. These
encounters are invaluable in terms of eliminating misunderstandings. System prototypes are presented with
suggested changes documented and made.
The budget and schedule should reflect unanticipated changes. When the unanticipated occurs, immediate
communication must be made to the appropriate parties, who must in turn
understand that can cause the budget and schedule to change. Superiors must be accessible. All this should be communicated and
understood up-front before the project begins.
Quotes Worth Noting
“Many
of the great ideas are not precipitated by the customer. While the customer knows what he wants, he
doesn't always know what's possible.
And that first dawned on me in my earliest days in business. When I was new at IBM, working in sales and
taking a management-training program in Sleepy Hollow, New York, I came back to
my room grumbling about the lack of speed and reliability of the tape drives,
and wondered why the engineers couldn't do something about it. My roommate stared at me with a look of
total exasperation. ‘Boy, you guys in
sales are all the same,’ he said. ‘You remind me of the
farmer in 1850. If you asked him what he
wanted, he would say he wanted a horse that was half as big and ate half as
many oats and was twice as strong. And
there would be no discussion of a tractor.’” -- David Kearns, former CEO of
Xerox
“If
you ask me to name the proudest distinction of Americans, I would choose --
because it contains all the others -- the fact that they were the people who
created the phrase ‘to make money.’ No
other language or nation had ever used these words before; men had always
thought of wealth as a static quantity -- to be seized, begged, inherited,
shared, looted or obtained as a favor.
Americans were the first to understand that wealth has to be created.”
-- Ayn Rand