Project Requirements

Make Project Sponsors Write Their Own Requirements

It’s up to the project manager to spend time with those who are funding the software project to help them defind exactly what they want before the peoject starts.

Without serious, specific consideration of what is to be created on this project during the requirement definition phase, the success of the project is severely jeopardized. The project owners need to convey what they want this software to do, not how the programmers will go about producing that result.

Convince the project owners that they must be involved in the process from start to finish. Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome. Otherwise, the project cannot produce the satisfactory result they are expecting.

Favor the Simple Over the Complex

The best softwareproject managers absorb complexity from all sides - from the programmers, end-users, managements - and never amplify it. Simplicity doesn’t happen accidently. It needs to be actively cultivated. Complexity is what happens when you aren’t paying attention.

Keep it Simple

If your software is not flexible enough to quickly adapt to changing requirements, the project is dead even before it has begun. Do prototype.

Production cycle: defining a small set of requirements, producing a prototype of the stated requirements, and obtaining feedback ensures that all project stakeholders are always on the same page and everyone is comfortable with what is going on. By religiously following these simple techniques, every software project can reach a successful conclusion. Especially if success is defined as a happy customer and working software that provides the useful business function for which it was created. Each cycle should be as short as possible - not longer than 2-3 weeks.

Questions to think about:

  1. Is it more important that the project is down quickly, with few bugs, or on small budget as possible?
  2. What resources and skill sets are crucial to create the software they want?
  3. Are they making these resources available to the team?
  4. How will the software be used to run the infrustructure or make money for the company?
  5. Are the time realistic?
  6. Are they written into a customer contract, tied to an important holiday date, or part of the elaborate marketing plan?
  7. How easy is it to use your application?
  8. How easy is it to add a new feature to your application?
  9. How easy is it to request a new feature? Report a bug? Deploy a new version? Roll back to a bad version?