You've heard war stories of companies trying to implement
off-the-shelf software solutions or create new systems. Maybe you even
participated in one or two? Many of these efforts took longer and cost more
than expected. Others were outright failures that negatively affected the
company's results. Let's look at 3 reasons why IT software projects can be
challenged or fail.
The Standish Group conducts an annual survey to find out why
some IT software projects succeed and others fail. Survey year after year shows
that about a third of projects are successful: they are delivered on time, on
budget, and delivered as promised. Most projects fall short: they are completed
late, over budget, poor quality, or a combination of these.
But it shouldn't be like that. We can succeed! It starts
with understanding the most common causes of problems with a software project.
The 3 Most Important Factors in Problematic and Failed
Projects
1. No user input
Imagine a software project where the project team completes
the project on time and on budget. But the software does NOT meet the needs of
users. Why did this happen?
Project teams are on fire! Everyone wants the software of
yesterday.
So how do most project teams react to this? They miss an
important stage of cooperation with users. These teams make assumptions about
user needs without even asking.
Oh, you wanted to preload the data? I did not know it.
Do you want your customers to be able to access their policy
information online? Why didn't you say it?
Users assume that project teams already know their needs. It
is not always so. In fact, teams often don't know.
In most cases, users first see the software during training,
not earlier in the project when requirements are received or when the software
is designed and configured. Even when the test is running. Opportunities for
user input are limited, resulting in lower quality software.
“The hardest part of building a software system is deciding
what to build. No other part of the conceptual work is as difficult as
establishing detailed specifications, including all interfaces to humans,
machines, and other software systems. No other part of the job cripples the
resulting system so badly if done poorly. No other part can be fixed
later." — Frederick Brooks
2. Incomplete requirements
Not a surprise. If the users are not involved, the
requirements, the needs of the users will not be understood. What happens in
these projects, do they use traditional or agile approach? Missing requirements
are discovered later. And refinement begins, which negatively affects the
schedule and budget of the project, as well as the morale of the team.
3. Changing requirements
Project teams complain that users don't know what they want
and constantly change their minds. Sometimes this may be true. But what do you
expect if users are not asked for feedback early on in projects? In addition,
we live in ever-changing industries that require us to be able to manage
change.
Leading IT software projects
I know you're smarter than the average Joe. You know that
doing the same thing and expecting different results is crazy. Let's take a
powerful and completely different approach.
