realistic_blueprints-1600x1200

Six Questions You Must Ask Before You Start a Software Project

Why do 70% of software projects fail?  

Kind of a scary number. There are lots of reasons, but oftentimes the failure starts during the planning process. More often than not, the project has failed before it even gets started!

This reminds me of a house my wife and I toured a while back.  The realtor allowed the homeowner (who had actually built the house) to join us on the tour of the house. When we entered through the garage on the lower level, he made a statement something like, “I didn’t have a plan when I built this place. I just poured the basement floor and walls, and started building.” Without going into a lot of detail, the place was a mess.  It seemed like the whole thing had been simple cobbled together with no rhyme or reason.  One room upstairs didn’t even have any windows. Needless to say, we didn’t buy the house, and I would be surprised if anyone did. The build of that house failed during the planning process – or more accurately in this case, the lack of.

As a business owner or a company leader,  you may be ready to embark on an internal software project or perhaps you are planning on contracting a software development company to do this.

Before jumping in, however, take some time to think through the questions below:

 

Question 1 – Have we allowed enough time?

One of the main reasons for project failure is underestimating the amount of time the project will take.

For the most part,  a good development team will be able to give you a solid idea of the time required.  Most likely this estimate is longer than you would like.  The temptation is to begin the “time negotiation” game.  This rarely ends well.

 

Question 2 – Have we minimized the feature set for the first release?

Another big reason for failure is “scope creep”.  Designing a really cool application with lots of bells and whistles can be a lot of fun. Getting it finished and usable is a completely different story.

The first goal is to define the minimum set of features you need and get the application into the hands of the users.  Once your team starts to use the software you will quickly learn what is really important.

It’s usually not adding one big feature,  which causes problems, but the addition of lots of little things. These extra feature ideas can come in from everywhere.

Many of the feature ideas are good but not necessary. The best way to manage this is to have a second release in mind as you work through the development process. This way you can push the great idea to the next release and keep focused while delivering the release you are working on.

 

Question 3 – Can we use the agile development process?

In the early stages of software development,  a project started with an extensive requirements gathering,  design and specification phase. In a big project this could take months. Once the design and specification was done the project then began.

Work would continue until the software was built. There was minimal or no interaction with the end users. This process could take months or even years.

By the time the software was done the needs of the end users changed considerably and the software no longer fulfilled the purpose it was designed for.

Sometimes a project is delivered and it does not fulfill the purpose for which it was built. This can happen when the development team writes the software with minimal interaction with the target user.

On the other hand, the agile process allows several small deliveries with a healthy discussion between the end users and the development team. Oftentimes what seemed like a good approach at the beginning of the project does not work as anticipated.

The agile process allows for ongoing changes throughout the course of the project which will lead to a much better final product.

 

Question 4 – Do we have the right end users available with enough time to work through the process?

In relation to the point above, if the end user does not have enough time to use the latest software delivery and provide good solid feedback to the development team, it will have a negative impact on the project.

 

Question 5 – Do we have a strong development team with the right leader?

In software, the right leader can make or break a project. If you are working on a big project make sure you have a leader who has successfully completed a big project. Interestingly enough, software development consists of both art and science. Experience helps manage the art. Skill and knowledge helps manage the science.

 

Question 6 – Who is going to provide ongoing support?

Developing and maintaining a new software package is more like having a baby than buying a new car. It can take on a life of its own.  It takes constant care and maintenance. Things can go wrong when you least expect them to go wrong.

Most likely the software you develop will be performing a critical business function and will bring great value to your company. You become dependent on it. This is  good, but you need to have a team who can fix problems when they arise.

The support team needs to be able to respond quickly and have a thorough knowledge of the software so they can find the problem and get you back into production.

 

Conclusion

Custom software is not for every organization, but more and more companies are creating software to help them solve problems and scale their business to capture new opportunities.

I have been involved in developing software for most of my adult life. I have seen, and been part of,  both triumphs and failures.  

The failures are painful but help to reach the triumphs.

Ah…but the triumphs; there is something about working on a team to build a software product which then allows a business to accomplish things they never thought possible!  

Having an end user catch you in the hall and tell you their job is enjoyable again, or watching a business expand significantly because of a new software package you created for them,  makes the journey all worthwhile!

 

Have questions about how custom software could work for you? Contact me at bob@sevenverbs.com.

 

shutterstock_165362696

Spreadsheet “What-if’s” Keeping You Awake? You Need a Web App

So you have created the world’s best spreadsheet. Everyone in the office and in the field loves it. It has shaved hours off the time it takes to bring valuable information to your customers and prospects.

But… you find yourself spending more and more time supporting the tool and waking up in the middle of the night thinking (worrying) about the “what-ifs” of this beauty which is slowly turning into a your personal beast.

One morning you wake up and decide to recommend taking the spreadsheet you created, and finding someone to make a web application which provides the same functionality. Knowing there will be a cost associated with this, you write up the 3 “what-ifs” that are keeping you awake at night:

What-if someone uses an old version 

Wouldn’t it be nice if the first spreadsheet you shared with everyone was the only one. Not so, there have been many many versions generated.

As a matter of fact there are about 100 people using this spreadsheet and you have released 20 versions. No one wants to delete old copies means there are probably 2,000 copies floating around out there.

You have created a versioning system but there have been several instances where someone in the field has used the wrong version, which has caused some embarrassing moments with customers and prospects.

What-if someone changes a formula

You have locked down the calculations as much as possible but there are a few places which need to be left unlocked. What if fabulous Frank our sales guy – who thinks he is a spreadsheet wizard – decides to “tune” things up a bit?

What-if this gets in the hands of our competitor 

Both the inside and outside sales force come and go. It would be very easy for one of them to take the spreadsheet with them when they move to a competitor. This spreadsheet provides your company with a nice competitive advantage. If it got into the hands of one of your competitors it would be relatively easy for them to replicate.

You set a meeting with your boss, have a discussion about the “what-ifs” and she gives you the approval to find a company to make this tool into a web application.

Three months later

Your inside and outside team are raving about how much easier things are with things running on the web. (Fabulous Frank in sales is complaining because he can’t make changes to the calculations but he will get over it).

The time you spent supporting the spreadsheet is now spent adding new capability. The only “what-ifs” you are thinking about are related to what-if your bonus is big enough to take the trip to New Zealand you have always dreamed about.

You’re not the only one who has struggled with the “what-if’s” of spreadsheets. These headaches are all too common, but they’re very easily remedied by moving your spreadsheet to a web application.