What to Consider when Starting a Software Project

Why Projects are not as Successful as they can be?

Choosing the right software development consultants

Should you hire Computer Science Majors as Programmers?

Choosing the Right Database

The Pitfalls of Forward Planning

Choosing the Right Programming Language

Report Driven Design

Problem Solving

What items to consider before starting an application Project

Below are questions you should consider before starting a software application project. Most of these questions are relevant regardless of whether you choose to outsource the project or do the majority of the work in-house.

1. Who will be the users?
2. Why are we doing this?
3. What is my budget?
4. Do we have the resources and the knowledge to do this in-house?
5. Are their off-the-shelf products that already do what we need?

Cost vs. Benefit - Return on Investment (ROI)?

It is a given that you should not be undertaking a project unless you expect the return on investment (ROI) to be positive.

Return on Investment need not be measured in monetary terms although in most cases it is because money is an easy thing to quantify.

With that said, it is important to itemize the potential benefits of a project against the potential costs.

Who will be the users?

It is important to keep users in mind. For example if your employees are overworked and really busy, the last thing you want to give them is a screen with a lot of fields to fill in with no explanation of rhyme or reason just because management thought it was a good idea. What you will end up with are a lot of blank fields and a lot of misused fields which in the end will make no one happy.

You should also involve the users in the decision making process by asking them if they feel a need for a change and what features they would like to see.

Why are we doing this?

You should know what features you are getting out of an application before spending the time and money for it. The best way to quantify this is to list each feature of the application that you do not already have and how this translates to an externally observed benefit

Examples of what we mean by benefits

• Reduction of manual labor by automation of a mundane task such as auto-generation of a company report which leads to increase in productivity
• Greater involvement of customer leading to increase in customer satisfaction
• An automated notification system which sends notices to sales reps when they are falling behind on customer calls. This will improve customer satisfaction without increased cost
• Overall improvement of customer satisfaction leads to repeat business and customer referrals
• Keeping up with technology. Current Platform will soon be obsolete and no longer supportable or code was written inefficiently and very time-consuming to add new features

What is my budget?

How difficult and How important?

You should be realistic about the outcomes of a project. Accept the fact that not all desired features may be reasonably achievable or be achievable in the first version of an application. With that said it is very useful to rank each feature set by two main factors Time and Difficulty to do: Which translates to money and Feature Importance. You should also have a brief descriptor for each feature and how it translates to a goal you outlined in the "Why are we doing this?" section.

It is not imperative and in fact very difficult to give each item a specific value. Instead simply just order them by these two facets.

Estimated Cost

Now that you have your wish list - you can either estimate the cost yourself (if you are doing the project in-house) or get some quotes from outside vendors.

If the price seems more than can be afforded at the moment or very close to what can be afforded, then trim it down using the weights of importance vs. cost.

Next multiply this number by a Fudge factor. The fudge factor varies slightly as a function of how detailed your wish list is, how stiff it is (e.g. the likeliness that things not on your list somehow become deemed critical), how large the project is.

The fudge factor should be somewhere between 1.15 and 2.25. Projects with a programming time expectation of above 1500 hours fall in the 1.5 and higher range.

Decision to Get Off-the-Shelf, Outsource, In-House?

For every software project there is most always a decision between Outsource, Off-the-shelf, and In-House. The in-house decision is easy to dismiss if you have no programming staff. The harder decision will come with application maintenance because although it may make sense to outsource the development of an application, it may make more sense to maintain it In-House or a combination of general In-House maintenance and outsource for difficult situations.

We'll briefly cover these in the remaining sections.

Off-the-Shelf

When we talk about Off-the-Shelf, we are referring to pre-built products that you can buy or acquire that do most if not all of what you need. Off-the-Shelf makes the most sense in the following areas

• When what you need is something that lots of people need and the minute details that separate your needs from others are very small or there is a large following of like-minded people
• The cost of developing what you need is very expensive

Examples of things that should be Off-the-Shelf are

• Operating Systems -- everyone needs one and very few people can afford to build their own
• Word Processors, Spreadsheet Apps - again everyone needs one and the kinds of things most people look for in these are the same.
• Browsers, Email Clients - here we have our preferences, but again there are enough people in this world that want the same thing that it is easy to find suites that do what you want
• Database Management Systems -- things like DB II, Informix, Microsoft Access, Microsoft SQL Server, MySQL, SQL Lite, Oracle, PostGreSQL

Then there are the grey areas where sometimes it makes sense to get off-the-shelf and sometimes it doesn't. Examples of these are below

• Accounting packages
• Payroll Applications
• Enterprise Resource Planning (ERP)
• Customer Relations Management (CRM)

Then there are the less grey areas where it rarely makes sense to get Off-the-Shelf

• Your website - because you are trying to distinguish yourself from the pack, you don't want to look like everyone else. Even in this respect there will be some parts of your site that you may choose to go the Off-the-shelf route such as a bulletin board, shopping cart.
• If you are developing your own product - then you may use off-the-shelf controls, but the core of your app will definitely be custom-built.
• You are developing a mission-critical app that you need to tie seamlessly with your existing apps or to work the way you do business. This is what separates you from the rest of your competitors so you don't want it to be off-the-shelf entirely.

Finally if you go the Off-the-Shelf route, keep in mind that any customizations you need to make will be at least twice as hard to do with an Off-the-Shelf product as with a custom built application. So you should look for something that fits most of your needs. Then there is the issue of excess baggage in that you often get more than what you need with a straight off-the-shelf package, which often translates to screen clutter and need for more user training.

Outsource

The decision to Outsource vs. In house is an easy one for small companies, and a bit harder for large companies. Then there are facets of Outsourcing such as the now popular Offshore Consulting which skews the dynamics a bit.

Offshore vs. On-Shore Consulting

Offshore Consulting as everyone who is familiar with the software industry knows is when you get the development and sometimes the project management and process work done where rates are significantly cheaper than home - usually in a different country.

Rather than look at Offshore Consulting as some new way of doing business - we choose to look at it as any old consulting where you can not meet face-to-face with the developers. It is always a given that a business will look for the best product in terms of price vs. quality.

With that said Off-shore vs On-shore is a non-issue and instead what you should consider are the ups and downs you get. After all we have many clients that we have not physically seen, but have had a long and prosperous working relationship with - we live on one side of the US and they live in the middle or elsewhere. Does that make us Offshore to them? Its merely a matter of semantics. What is important is what makes a consultant right or not right for you.

• How experienced are these consultants?
• Is there a language/cultural/time barrier?
• How trust-worthy and stable are these people?
• What are their rates and what is their quote for the work we have proposed? Note that rates are not necessarily enough because one consultant might charge $100/hr, but get things done twice as fast as the $65/hr one. Also some consultants in their proposal may outline more than another group - one group may add something that wasn't explicitly asked for, but is implied by a requirement
• Do they come recommended. If recommended by someone you know the better because then you know that it is most likely a true recommendation.
• How many middle men - with large firms that provide cheap labor, they often buffer this with high project management rates and hours. Some of this is justified for huge projects where armies of programmers need to be directed from distant corners of the globe, but makes little sense for smaller projects. With that said unless you are a big company yourself doing a big project (and even if you are yourself), you should probably be very cautious when dealing with big consulting firms which are well-known for their army of middle men.
• If you can not have direct access with the core developers, can you have phone access? Are you comfortable working in these conditions?

Del.icio.us | Reddit | Digg | BlinkList | Furl Spurl | Simpy