6 Steps To Ensuring Your Software Development Project Will Fail

Since the inception of software development, business development and technology departments have been locked in a death match. The main issue stems from a group of R-Directed (pattern recognition, holistic reasoning) thinkers in bizdev communicating with a bunch of L-Directed (logical, analytical) thinkers in technology. The majority of the problem can be ascribed to two main issues:

• Improperly set expectations
• Poor communication.

Here’s what everybody involved can do in order to accelerate the impending catastrophe.

Step 1: Don’t Plan

The great thing about not creating a budget is you don’t have to worry about your project going over budget (score one for the good guys). Moreover, no budget means no business analysis = less work for you. Who really cares if the new software costs $100 or $100,000 the clients are going to love the new software that prints greeting cards on both sides of a PDF.

Business analysis will force you carefully construct use cases, a requirements document as well as a technical specification in order to determine scope, schedule and budget, all of which will help you ascertain if there is any value in your software proposition.

Use cases require communication between the client, business development unit and software development team. This is an invaluable part of the process which will help everyone involved determine if in fact there is a business case and/or a consumer need for the proposed solution.

A requirements document will help bridge the gap between the assumptions you have made (I’m sure the developer will know that everyone on the email list should be contacted when you create a new evite) and the understanding that the developer gleams from reading your document (why would you want to email everyone on the contact list when you create a new evite?).

Finally the technical specification is where the software developer can take your requirements document and create a drilled down estimation of how long each and every component will take to develop. This is typically followed by a signoff process where the business team and the development team sit down together to determine if both are on the same page.

If you’ve followed my recipe for disaster, at this point you have no idea how much it’s going to cost, if the users want it, and when it’s going to be done. You should be well on your way to:

Step 2: Change Requirements Often

One of the most difficult projects to complete is one that changes regularly. “Oh can the software do this too?”  Nothing will extend your project faster than adding requirements on the fly. Imagine constructing a car based on the premise that it will have three wheels. As you near completion the head designer let’s you know that he wants a fourth wheel.

Typically changing requirements are a result of poor planning (see Step 1). Managing what may seem like a simple change can often lead to massive unforeseen architectural changes to the fundamental software design. But since you don’t have a scope, schedule or budget, massive architectural software changes shouldn’t bother you too much.

Step 3: Let the Developer Manage the Project

Nobody understands your needs, the needs of your customers, and the needs of your company better than you.  So, after you’ve jotted down the details of the software package you need urgently (in bullet point of course) just turn over the difficult task of balancing cost, time and quality, to the developer. After all, he’s the L-Directed thinker isn’t he?

Step 4: Eschew Policy and Procedure

Let the development team create code right on the production server, work without the safety net of a software repository, and definitely don’t worry about small iterative release cycles.

Breaking down your project into short iterative release cycles will force you to review the software project at two or three week intervals (intrinsic project management). You will catch errors in assumptions early and often. Additionally you will catch software bugs early and often.

Further, your project will be broken down into logical units of work that can be developed in a reasonable amount of time. Your development team will string together a series of small victories that will build confidence and demonstrate progress.

Step 5: Cut off all Communication

If something goes wrong with the project, I’ll get an email, right?

Step 6: Let the Customer Test

The best way to test something is by having it battle hardened. Let’s just put it up and see what happens!

Software development is a discipline like any other engineering process. In order to achieve success both sides of your company must work together to plan the project carefully (set expectations and manage change), set up policy and procedures (provide a framework for proper development), and communicate throughout the process. Invest the time in your project up front and you will reap the rewards of a successful software development project that is delivered on time and on budget.

By the way my song of the week is the Fake Blood Remix of Miike Snow’s Animal. Enjoy.

Share on Facebook