10 main reasons why software development projects fail and how to prevent them. Some cool tools we use - click through the links!

1. Miss any of these 10 important points in a
software development project and you are most
likely going to fail!
Medullus Systems
Excellence in software development, Cloud, EDI, Reporting, ERP, Sharepoint, Legacy software, Project Management &
Consulting…for your business

2. Who should read this: Anyone remotely connected with IT!
Tips: Be sure to click through the links - there are some cool videos and tools we use that you might find helpful.

3. (1) Start an official charter meeting - even
if it is a 1 day project, and list everyone
involved in the project
It just makes the project official. Create a
document, project asset, minutes or it can
even be an email to all involved stating (a)
project name, (b) project manager, (c) team
and responsibilities (could have a RACI if it is
a more involved project), (d) briefly, what the
project is going to achieve

4. 2) Create a scope baseline, get it signed by the project champion
and make it visible to every stakeholder
We call it “spec freeze”. Scope, simply put, is the sum total of what
the project needs and agreed upon by all parties. The reality is that
the scope is forever changing. James in Accounting thought of
something new, Mark in procurement had a better idea, Jill in
Inventory thought of one exception…you get the picture. We create
detailed wireframes upfront - it can be time consuming, but it is totally
worth it. EVERY TIME. It gets the project “live” in front of the end user
before we even start to develop. So once James, Mark, Jill and the
gang is sure (at least as of now!) we stamp it as a “scope baseline”.
Any change is recorded but it is kept in a queue till after we deliver on
that initial scope baseline. For the customer they see an end and not
an unending project with changes upon changes. It keeps our
development, testing and implementation clean.

5. (3) Research and find out all the negative
stakeholders (not just the positive ones)
Every project has at least 1 negative stakeholder,
someone who is negatively affected by the
outcome of the project. It could be a person, a
department, a customer, a vendor, a belief or
even a competitor. Sometimes such impacts
cannot be avoided. But it is a good idea to know
how to work through them. Surprises are never
pleasant during a software development project.

6. (4) Create 2 specs - one for the techies and one for the
business folks and make sure they are both synced with
the scope
In any software development project you will have to find out
who the main consumer of the software will be - it can be 1 or
more users. That user or users will be able to articulate what the
project needs to do. As a software architect and also as a
project manager you should be able to see the software from
the eyes of the business as well as the eyes of IT. If you cannot
do this, then make sure you have someone who can do that or
tag team. When you are creating the specifications, create a
user spec and a software spec - make sure these are in sync.
Updates to one should update the other and communicated to
the right parties.

7. (5) Regardless of your project management methodology
(waterfall, scrum etc), make sure you have a detailed
work breakdown structure
Take a project. Break it down into modules - a module is a
finite part that can be developed and tested independent from
the rest. Now take each module and break it into tasks. A task
is a finite part of a module that can be measured start to finish
- one to which you can clearly add a start and an end date.
Next take the task and break it (if you can) into chunks that
makes it easy to estimate time. There are many ways to
estimate time - but increments of 2, 4, 6 or 8 hrs works for us.
So 5 hrs is 6; 3 hrs is 4 (round up). We also use PERT
methods if there are several unknowns in the beginning.

8. (6) Write out the test plans in a bug
management system - it could even be google
docs or excel - but write it
When you articulate and write down a test plan
your testing becomes more methodical. The
project can be just 1 text box and 1 button. But
when you start to write it out in steps 1, 2, 3 etc
you will see a 4th test that you would have
probably missed. You may use automated testing
tools, but for functional testing this is a must.

9. (7) Track progress daily - project the finish line
based on current completion
Especially true for those long projects, spread across
multiple teams, time zones and sub projects (more like a
program). A daily top down view of the project
milestones, KPIs like burndown charts or % completion
or earned value measures should be assessed daily -
you can do it start or end of the day. Surprises spring
when a project is “sleeping” or on “auto-pilot” - those are
not good words for a software development project. It
needs to be tracked, monitored and managed. DAILY.

10. (8) Keep communication channels open across all
team members
Getting mathematical! Number of channels = n*(n-1) - so if
5 people are involved, that creates 5*4 = 20 channels - that
is a lot of communication! The single most reason why
projects fail is lack of clear communication and open
channels. Daily 15 minute meetings (scrums) is one good
solution. It should be unofficial - answer 3 questions - what
did you do yesterday, what will you do today and what
roadblocks are you facing to get the project done. Have
each of the 5 people (or whatever the project team size)
answer these. Another option is to use a collaboration tool
like Basecamp, Producteev, Asana, Sharepoint, Zoho etc.

11. (9) Be honest - dead honest
If you messed up own up to it right then and there with an apology,
but more importantly, with a way to fix it and how it will impact the
work breakdown structure and the timeline. It lets the project
manager recalculate, crash the project or rearrange resources etc.
If something is sensitive, but you feel it will affect the success of the
project be honest and mention it, but mention it to the right person.
First explain why you are going to talk about it and then explain
how the situation will affect the project.
Politics is a great way to get things done! But politicking for the
sake of it or to hide inefficiencies is a cancer to any project. Be
honest and call it out if you see it. Create the “political arena” where
it can be brought out to the key stakeholders.

12. (10) Always close the project, finished
or not, successful or not
Let the project champion know “this closes
the project.” Then write 1 (just 1) main
lesson learned from the project. This really
helps. At a glance you can see how many
projects you have done (count the lessons
learned!) and before starting a new project
it is a good read.

13. Have a good time with everyone, enjoy
the ride and remember:
“The goal of a software project is to
solve a business problem. It is
empowering when you know that your
software will help a business to
prosper.”