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