THE most important phase of the project is establishing the requirements.

The most important phase of the project is establishing the requirements.  The most important time to establish these requirements is during the proposal.  Unfortunately the proposal phase is frequently rushed, under funded and manned by personnel who will not be delivering the product (which means they are probably lacking the expertise needed to provide a detailed versus best guess proposal).  This means that you will probably wind up with a project that is under funded, poorly defined and is expected to be delivered in half the time you really need to get the job done.  The only way to avoid this dreadful situation is to nail down your requirements, to the lowest possible level possible, with the customer’s help during the proposal phase. (In some cases, as in government contracts the customer is a representative of the people who will actually use the product.  To make things worse this representative can be some distance from the user and does not have a background similar to the user.  In these cases you must be able to work with this representative to get to the user or make sure the contract is padded or cost plus because your going to need a safety net).  The requirements must be defined to the lowest possible level and someone who would actually be creating/providing the product must review the impacts of these requirements. (If your company mass produces a product or has an excellent database of actuals from previous efforts this step will be much easier).  This means that you must find the time to get the product maker and the end user together.  Together you must be able to go through each requirement and find every derived requirement possible before you turn in that proposal.  Warning!!!. . .This process is tedious and not much fun.  You must define each requirement and each sub requirement until you run out of requirements.

I will provide you an example from the project I was asked to close a couple months after the last article was written.  The purpose of this effort was to upgrade the simulated radio and navigation systems for a military aircraft simulator.  This project was over budget and already 6 months late and the customer was not too pleased. (To make matters worse we were also trying to win a 6 year bid on continuing our overall operations at the site where I work). The first thing I did at this point, which is the first thing you should do in a proposal effort, is to make sure the requirements are adequately defined.  As it turns out they were not.  For example the Statement of Work said we were to provide a satellite modem simulation (hardware and software).  The requirement literally said “provide the satellite modem system”.  This modem has 150 menu selections.  None of these functions were included as requirements.  This meant that we did not know which menu functions need to be simulated and which needed only to have working menu functions.  This meant that all we really knew was that we had to provide a new device that simply powered up and provided a user interface.  The user interface would do no more than step through menus.  No functionality would be realized because we never found out what that was.  As this is only one example of the requirements dilemma we were in (there were several more new/updated systems) I felt it necessary to get the customer’s representative together with the end user and my team to identify the specific requirements we needed to deliver.  After the customer voiced his justified displeasure with our not acquiring this data much earlier we obtained those requirements, figured out a game plan and negotiated project closure.  I assure you that if we had accomplished this step during the proposal we would not have delivered 9 months late and our customer would have been much happier.  I know this because we would have not spent months working on requirements we guessed the customer wanted. 

The lesson here is simple.  Define each requirement down to its lowest level during the proposal phase.  This means you must know what your customer wants each items to do, what each knob should do, what each component should do, what each service should provide down to the lowest level possible.  If you find yourself with only the time, expertise or manpower to get in the ballpark then tell your customer that and pad heavily or structure a cost plus contract.  Another route may be for you to break the project in phases and bid each section, as data becomes available.  Either way you attack this problem you must resolve it before delivery.  If you do not the customer will figure it out and not hesitate to let you know what you did not provide for them.