If you are in the software development field, then you have probably been involved in some of the following classic pitfalls during a software development project:

These are just some of the classic mistakes. I like to call these PPT – Process, People, and Technology. I for one, have made some of these mistakes. By writing them down and defining them, just like in history, we can learn from past mistakes and use them to guide future project planning and risk management. If this article saves just one project from failure, then it is worthwhile.

1.      Process

Overly Optimistic Schedules

Schedule creation is one of the primary sources of failure. More often than not, schedules are overly optimistic. Creating an over-optimistic schedule upfront can unnecessarily add pressure to the development and QA teams and ultimately result in a failure to deliver the project on time.  Pretty much no schedule ever executes with all best case scenarios, and some hiccups best are accounted for in the schedule.

Ineffective Risk Management

Risk must be planned and actively managed throughout a project; only one thing has to go wrong, and the entire project could be in jeopardy. The problem is particularly true for a rapid application development project and especially true for a Minimal Viable Product (MVP). Potential high risks could be long pole tasks; complicated tasks are automatically high-risk, scarce skills sets, and external customer development.

Wasting time at the “warm and fuzzy” stage

Just like in a new relationship, the beginning is full of excitement and anticipation. Often Business Analysts (BAs), planners and developers are still transitioning off a recent project when the new one starts. In considering a new project that is a year away from completion, the tendency is to kick back and relax a little. The developers may be waiting for the BAs to complete requirements and the schedule may not be fully flushed out. It is critical not to fall behind schedule at this juncture because it is far more difficult to try to gain back these few weeks near the finish line.  Perhaps development work can be staggered to start on those requirements that are completed. You need to stay ahead of the game when you can to make up for those unexpected problems.  To keep on schedule, you constantly need to be prepared to make adjustments.

Lacking or Rushed Design

For new features, there is often a rush to jump into coding. The thinking is to get something out there as soon as possible. If you are lucky, this approach may result in software that works on a basic level for a couple of users, but often does not scale or interface correctly with other parts of the application or is ill-designed to support new features supporting the company vision. This then results in “tweaking” the software until you have a coding hell and a situation where if one business requirement changes, then the whole system breaks down or becomes very fragile.

The result is that the real time taken for the feature far exceeds what it would have been if time had been initially allotted for a proper design.

Failing to Learn From History

In the stock market, there is a saying “past performance does not indicate future results.” However, in software development, past performance is a great way to forecast future development schedules. It is critical that you maintain statistics on previous projects. Imagine you are in a meeting with your management and you are asked: “We have around 400 requirements for customer ABC, can we do this in six months?” Unless you have tracked history, you will be unable to provide a ballpark figure on the spot. However, if you had gathered statistics, you could answer with something like, “In prior projects with around 400 requirements, no project has been completed in less than 12 months.”

Feature Creep

No matter how good your requirements are, the typical project experiences around a 25% change in requirements during its lifetime. These are requirements that the customer may not have considered at the beginning but become essential. Typically, this adds about 25% to the project schedule. It is very important this known variable is factored into the schedule. Do not submit to wishful thinking or management pressure to hope for the best.

2.    People

Motivation and Weak Staff

Motivation and personnel lacking the necessary skill sets are the biggest factors affecting productivity. If staff feel undervalued or feel like they are “just another number” or even worse, they work so many hours their bonus amounts to $1 an hour, then productivity will suffer.

If the company hiring process is geared towards hiring staff quickly instead of hiring the best person fit for the job, then although the work may start sooner, it will end up taking longer overall.  Hiring the wrong person can delay the project more than if the person was never hired in the first place.

Adding People Late in the Project

Adding more people is the classic mistake. If the project is running behind schedule, then the thinking is that by adding people, more can be done in the same amount of time. However, in reality adding more staff just takes time away from existing employees who end up needing to train the new people. Additionally, the new staff members will make more mistakes, further wasting time in QA and development rework.  Also, some types of tasks cannot effectively be spread among multiple people.

Work Environment – Open Offices vs. Cubes. vs. Private Offices

Open offices vs. cubes. vs. private offices, is often hotly debated. The open office was originally conceived by a team from Hamburg, Germany, in the nineteen-fifties, to facilitate communication and idea flow. Many companies have made this very popular, especially in Silicon Valley such as Google.

But a growing body of evidence suggests that the open office configuration undermines the very things that it was designed to achieve. A 2013 study found that many workers in open offices are frustrated by distractions that lead to poorer work performance.

Noise in the office has always been a source of distraction to workers. It is the type of noise that is critical. If you can hear every conversation around you, then you will naturally listen in case, “are they talking about me?”

If the noise is white noise, such as the white noise found in a busy Starbucks, then this is less distracting.

Lack of Effective Project Sponsorship

High-level project sponsorship is essential to ensure realistic planning, change control and control of scope. Without an effective executive sponsor to control planning and scope control between the vendor and the customer, this virtually guarantees project failure. Unfortunately, even the best software development and management team cannot make up for this.

3.    Technology

Often, developers and managers jump on the latest technology bandwagon. The latest buzzword appears online, and everyone is adding it to their resumes.

“Google is using it. Therefore it must be great!”

Yes, it probably is a great solution for Google. But unless you are solving Google-sized problems, then the best tool for your problem is unlikely to be the same as for Google. Choose the solution that best meets your needs. If a new development method or technique is needed, then account for this uncertainty in your schedule. The time saving from object oriented development and reuse from previous project code is often not as dramatic as expected.

These are just some of the more common mistakes in managing a modern software development project. If you would like to avoid making any of these in an ongoing or future project, please feel free to contact me. I would be happy to help.