IT Project Success Rates

IT development success rates are abysmal. When projects go over budget, miss their ship date, and suffer from feature creep or lack of proper quality assurance, no one wins.

The client isn’t happy, the users aren’t happy and the developer isn’t happy either. While research shows that this is a common problem, it doesn’t have to be this way.

Research shows that over half of the IT development projects undertaken come in late and over budget.

Projects often come in with fewer features and functions than originally specified, and nearly 33% are cancelled. This is often due to a lack of user input, changing requirements, and unclear objectives.

Studies indicate that approximately 2.5 million individuals are currently working on nearly 500,000 software projects in the United States alone. Of those, up to 66% will come in with fewer features and functions than originally specified and will exceed budget targets before delivery. Of the most expensive, half will eventually be cancelled due to low levels of quality and reliability.

Studies show a staggering 30% of projects will be cancelled before completion. Further results indicate over 50% of projects will cost 189% of their original estimates.

These various studies don’t measure the lost opportunity costs, which could easily be measured in millions of pounds. Intrinsic damage can be far more costly.

Many studies focus on large projects using enterprise software systems. So, you may be thinking, “Those studies apply to the big projects. I don’t need a structured development process because I require a much smaller solution.” That, in our opinion, is a very dangerous thought. The process we detail should be applied to every project, regardless of size or scope. The process is about being thorough and complete in our work and, therefore, spending more time on productive creative work, rather than excessive testing, debugging and modifications.

It is VERY important to MaJic that prospective clients understand our solution building process. This way, if MaJic is engaged in development, the client feels as comfortable as possible and can provide the required involvement that will greatly contribute to the success of the project.

Why do so many projects fail ?

Successful projects tend to follow a similar pattern regardless of the company involved in the project. There are a myriad of ways to fail when building software systems. There are only a very few ways to succeed.

Successful projects that finish on time and within budget and contain all the functionality the client needed and requested will have certain things in common. Our recommended approach to software development has been developed and refined over many years specifically for the FileMaker Pro database environment. The methodology itself is a product of not just our own developers but of many developers’ learning experiences in the FileMaker community.

To avoid project disasters, it is helpful to be aware of the common reasons for failure and to understand the importance of our process that will help avoid them.

Most failed projects experience one or many of the following characteristics. MaJic aren’t guaranteed project success by avoiding these mistakes. However, they do keep us from completing projects on time and within budget if we don’t overcome them.

By acknowledging their effect on a project’s success, together with our client we can use this list to help our customers understand the importance of our process.

Incomplete requirements

Even in cases where attention is paid to the requirements of a proposed solution, problems can occur if we haven’t had the opportunity or access to carefully and comprehensively collect your requirements.

Changing requirements and lack of change control

Changes always occur on every project. MaJic plan for it and expect it. However, MaJic don’t implement changes without assessing their impact and obtaining the proper approval from their client. We estimate the cost and schedule impact of each change, even if the project can absorb it. Little changes add up over time. With the help of our client we set priorities based on budget and schedule constraints. MaJic will explore options with the person requesting the change. In cases where changes or corrections are proposed during usability testing, we document what is proposed, but we don’t implement them until MaJic has received a formal approved specification modification from the client.

Unrealistic timelines

Many developers present timelines and project completion time consistent with the wishes of their client simply to win the project. Accelerated project completion rarely goes hand-in-hand with project success. Timelines should be realistic, directly proportionate to the amount of time required for development, and shouldn’t be impacted by any other influences. Setting unrealistic goals is worse than not setting any. Likewise, it’s unreasonable to hold project personnel to commitments that have become impossible. Either of these situations tends to de-motivate the team. MaJic work with the client to set reasonable, yet challenging, intermediate goals and schedules. Success leads to more success. Setting solid, reachable goals early in the project usually leads to continued success throughout.

Lack of executive support

If our client isn’t interested in the success of the project, or isn’t motivated to become properly involved, the chances of project success are minimal. Most clients support a project or they wouldn’t seek our development skills, but all members of the organization -including executives - must be willing to take a stake in the success of the new system in order for the project to succeed.

Lack of proper funding

In most cases, a client will have no idea how much development will cost until we inform them. It’s the responsibility of MaJic to give our client the clearest idea possible of how much a solution will cost before development begins. Once development begins it is important that the necessary funds are in place to meet the various stage payment the project requires. A ‘Down Tools’ situation can cause long-term success issues. Also, there is no benefit in asking developers to relax programming standards in order to reduce costs. Relaxing standards (cutting corners) tends to lower the quality of intermediate products and always leads to a rework later in the development cycle. It also sends the wrong message to the team as to the long-term success possibilities.

Insufficient user involvement

Software users don’t like change just for the sake of change. They must feel that the new system is a reflection of their needs, rather than just something different they now have to learn. MaJic will listen to the individuals who will use the system everyday, and build the system so it meets their vision. In some cases, developers are more interested in building a system they want to see rather than one the end-users want to use.

Lack of proper risk analysis

Every project will have risks. To minimize their effects, you may require MaJic to analyze the potential risks and take measures to prevent them from occurring, or to eliminate them outright.

Creeping user requirements

When requirements for a new system have been defined and agreed upon prior to development, there is still a very real possibility that more requests will be made after development has begun. MaJic have a process in place to accommodate and prioritize late requirements to prevent them from interrupting the success of the project. Creeping requirements pose a risk to 80% of management information systems projects.

Ambiguous requirements

Requirements shouldn’t only be defined and discussed, but MaJic needs to understand them completely in order to properly build them into the required system. The various parties involved will interpret vague requirements differently. This leads to confusion and unexpected results. MaJic will ensure requirements are clearly understood.

Poor communication between developer and client

MaJic clients will have an open line of communication so they can give complete and comprehensive input. MaJic will be sure to spend extra care listening to users wishes.

Unnecessary features

MaJic will only implement what’s required. Developers and analysts often think of additional "little" capabilities or changes that would make “their” system better (in their view). Again, these little items add up over time and can cause a delay in the schedule. In addition, deviations from the approved design may not satisfy your requirements. Time spent on features not requested or relevant to the functionality of the solution is wasted time, and can cause expansion of development and increase the possibility of coding error.

Overlooked user classes

One of the more common causes of project problems is when developers miss certain users or departments that will use the system. It’s important to determine who every user will be prior to development. The discovery of new user groups after development has begun can be costly and difficult to integrate.

Client’s project vision isn’t achievable or wasn’t shared with the development team

It’s the responsibility of MaJic to discover and adopt the vision of the client’s project. MaJic ensure they understand these needs and objectives and apply them appropriately to a new system. It is also MaJic’s responsibility to let their client know when expectations of a new system aren’t feasible.

House Construction Example

Development of a software project is analogous to building a house, in that a well-planned logical sequence of events can determine its level of success. Both situations benefit greatly from proper planning.

Create the blueprint

Any effective construction process, whether building a house or a software system, begins with creating a blueprint. A blueprint is the necessary first step in any development project. The creation of the blueprint provides a dialog between the builder and those requiring the building. It gives MaJic a chance to assess risk and make recommendations to their client on paper, before any requirements become too expensive to change. It gives all parties the chance to visualize the completed product and ample time to make changes before physical construction begins. Changes are costly and can require starting over again.

The “MaJic” of Proper Planning

Not only does proper design prevent problems by defining the system before we create it, but it also affords many advantages in taking time to plan ahead. A good design methodology gives us the skills needed to design a sound database structure. The process helps us take overwhelming amounts of information and turn it into a series of easily understood tasks that ultimately create a sound and complete database system. Learning and following our design methodology keeps our missteps and design iterations to a minimum. Of course, we’ll naturally make some mistakes when designing a database, but a good methodology lets us recognize the errors before our client has made a major investment in them.

The design process we follow helps us visualize time lines and costs realistically before we’ve started on development. It also helps us visualize the relational structure and logic of a system. That way, we can compare our plans against the system requirements to ensure all needs will be met by the new system - before we create it. Diagramming a system lets us fix relational issues before we’ve defined our first relationship. We can eliminate unbalanced relationships and add new join files where appropriate. These changes can be costly after development has started. Achieving the objectives associated with good design will save us time in the long run because we don’t have to constantly revamp a solution that was designed in haste. After we’ve completed a properly designed solution, it's easier to modify and maintain the system.

When solutions are developed in an “evolutionary” fashion (e.g., without the proper planning and methodology), the results are undesirable. Such systems usually contain scores of unneeded fields, layouts, scripts, and relationships that will only make the job of weeding through it all to find the problem much more time consuming. Most importantly, a disciplined development process lets the developer spend more time being creative and problem solving rather than fixing and diagnosing.

Process Outline

1 - Discover

Understanding your business is the critical first step. MaJic will work with the client to clearly understand your immediate needs and long-term goals, as well as your operating and technical environments. How will the system advance your business strategies?

Who performs the steps in the current business process?

What information will the system produce and use?

What are the major steps in the business process?

Who receives, uses and benefits from the products and services the planned system will produce?

2 - Define

MaJic and our client will agree on how the success of the project will be assessed. After we define and agree on project objectives, MaJic define the functional, technical, and creative requirements. What will the solution be?

Who will use it and how?

What will it do?

How will it work?

What will it look like?

Are there better ways to structure the organization and work roles?

Is information in the current system adequate, accessible, and easy to use?

3 - Design

MaJic then document the requirements and work with the client to refine them. MaJic build a data flow chart or a storyboard for the project to help you visualise and audit the work plan. MaJic also establish project scope, budget, and a detailed work plan. Finally, we create a detailed project proposal for the client to review and, hopefully, approve.

4 - Develop**

MaJic now build the final product. Taking special care to create the files, fields, relationships, layouts, and scripts in a manner consistent with the design documents and development standards. Constantly test the solution, and deliver it in stages to the client for review.

5 - Deploy

After MaJic deliver the final stages of the solution, we integrate it with the client’s existing systems. MaJic then test and quality assure the deliverable and ensure the client understands how to manage and maintain it. The result is a working prototype of the deliverable, ready for usability testing. This beta version is transferred to the client’s system for testing on the end user machines. Work commences with your staff to tailor the solution to ensure it is ready for deployment. The result is a custom, fully functional, and ready-for-launch solution.

6 - Denouement

For a period after the launch, MaJic monitor and analyze how the solution performs against the success criteria defined in the Discovery phase. MaJic, if required, can also conduct training sessions or assist the client in making organizational decisions to help us support the new solution. Further work with the client continues so that both parties can evaluate the new system to ensure we’ve met all expectations.

Development does not commence until the fourth step!

By this stage, MaJic will have developed the blueprint for your system and we’ll know everything our client requires in order for us to start a build. MaJic apply this process to EVERY one of our projects. Every client gets some incarnation of this process, regardless of the project size. The process doesn’t guarantee the quality of the code or the completeness of the requirements. However, it does increase the likelihood of genuine communication, realistic system requirements, and reasonable expectations. Moreover, it improves the likelihood that the project will produce a system users will want to use, and from which the business can gain an effective and efficient work system without creating unexpected, unpleasant side effects along the way. Step four is wholly dependant upon steps one, two and three being properly completed.