Software Project Management and the Art of Budgeting
Trust us to keep your IT projects on track. We have the experience to recognize and correct problems when they occur. Is your project over budget? Is it going to cost more than expected? Most often yes! Why is this? There are many reasons why a software project is over budget. One crucial task is to limit the requirements to match your customer's budget. The wish list must be pared down to match their funding. If a particular capability can not be given up, it must be put into a separate phase which can be implemented when the funds are available. Large projects especially have trouble narrowing their scope since the user base is so large and they are trying to be all things to all people. It sounds simplistic but the seeds of failure are planted here in the requirements definition phase if the scope is not limited.
A great deal of the success of any project depends on the depth of the customer's understanding of their needs. The client's knowledge of their own procedures allows the business requirements definition phase to proceed directly an inventory of mutually agreed upon and specific written requirements. Unfortunately employee turnover causes gaps in the knowledge of why certain procedures exist. In other cases there are simply too many departments involved to come to a satisfactory compromise on the requirements. Some other major reasons projects derail are shown below:
Major Reasons Projects Derail
Steps we are aware of and take to create a successful client relationships.
You attend too many meetings and do not get specific answers or conclusions
- You spent too much time defining the requirements and now there is not enough time left to actually implement the software
- You didn't define the functional requirements in enough detail and now they are assuming you will be delivering more than is feasible for your budget.
- You never could define the requirements in a few areas and now they are coming back to haunt you. The requirements definition is happening concurrently with the development.
You have under estimated the size of the learning curve
- You are encountering bugs in the system software.
- The software didn't do what it promised in the nice glossy color brochures.
- You can't even get your demo working.
- Some key people quit and you can't find people who know your new software packages and system software well enough to produce quickly. On the other end of the spectrum, staffing is also a problem when the technology is very old.
Why software projects are late:
- You do not have enough people.
- You do not have the best equipment.
- Your hardware is not fast enough or too many people are sharing the same resources.
Your staff is not talking to each other enough or your client is not talking to you.
- Your team members do not like each other and avoid communicating.
- Some aspects of the project are unknown and you do not have access to the information.
- Egos, empire building, or hidden agendas are preventing crucial communications.
- People who left the project did not document what they did or why.
- Your staff does not work in the same building and as a result, chance meetings which result in discovery of new information are not happening. You don't know what you don't know.
- Staff turnover has caused a gap in the knowledge needed to finish the application.