Fred’s Law #2: Requirements, we need lots of them!

As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.

Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:

  • You can create the illusion that you really know what you are doing
  • You look like you are being extremely diligent
  • You always look like you are extremely busy
  • You create huge amounts of documentation to support the illusion that you have been both busy and diligent

Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.

On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.

So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.

 

Share this post :

 

Fred’s Laws #1: Requirements, who needs ’em?

Well, I guess it is fitting to start out Fred’s Laws at the beginning of the process – with requirements.

If you really want to start of on the right foot, and get your project well on its way to a spectacular flame out, this is a fantastic place to start. Remember, the best way to figure out what your software needs to do, how it should do it, and what it should look like, is to get your coders right in there coding. After all, who knows what the user wants better than coders?

This is especially true if you are building something new and innovative, or if you are short on resources or time. Just think of all the time you will save by not having to talk to users up front. And, all those resources you would have wasted talking to users can be redirected to more important things like coding (whether they know how to code or not). Just imagine how far ahead of schedule you will be right from the beginning!

Now, estimation and scheduling may be a challenge without some definition of what you are building, but you probably will not be doing any real estimation or scheduling anyway (see later laws). If you need to have estimates and schedules to show to management, you can always make something up out of thin air (but make sure not to talk to your developers about it!).

(and just think how much time you will save talking to users later on, since you won’t have any!)

To be really specific, make sure you avoid any of the following activities, which are known risk factors which could lead to success:

  • Set up a system for capturing requirements, using Access, Excel, file cards, or any other tools
  • Establish a process to review and prioritize requirements, and assess their value versus cost
  • Define a process for managing changes to requirements
  • Involve users or user representatives in the creation and/or review of requirements

All in all, avoiding requirements definition should save a great deal of time up front, and allow you to focus on the important work of trying salvage your failing project.

Share this post :

 

%d bloggers like this: