Home Page     Contact Dave Thompson Consulting   Site Map

     Ten Reasons Software Projects Succeed

Dave Thompson Consulting

    408 Rose Drive    Allen, TX 75002  (Dallas / Ft. Worth, Texas)   Tel: 972-727-5670

Microsoft® Access and Office Custom Programming and Consulting Services

 

1. High level sponsorship

2. End user participation

3. Focus

4. Developer has understanding of the client's business

5. Client has understanding of the development process

6. Project management

7. Technical competence and maturity of the developer

8. Shared reality in a flexible environment

9. Open communications

10. Prompt payment
   

           

 

 

Sponsorship
A custom software development project should be sponsored at a level where the sponsor has funding authority, can resolve conflicts, provide leadership and influence across all impacted business areas, and provide the business focus for results. Projects that start without this leadership, are frequently doomed to failure later if problems arise.

Designing, developing, and implementing a new application means change to the organization. Sponsorship and leadership must be visible and active at a level within the organization to indicate the importance of the project to all participants. 

"Whenever processes are redesigned or the availability of information is modified ... work habits must be changed, existing social patterns are threatened, and the power and influence structure that has slowly evolved over time can be abruptly destabilized." Understanding Organizational Dynamics of IT-Enabled Change: A Multimedia Simulation Approach, Manzoni & Angehrn, Journal of Management Information Systems, Pub by M.E. Sharpe, Volume 14, No. 3, Winter 1997-98
- Return to top -


End user participation
End users should be brought into the process before actual coding starts. They may identify requirements that have not been identified. And ultimately end users need to buy into the process.

Additionally, end users should be asked to evaluate interim releases (early versions of the software during development). Watts S. Humphrey (A Discipline for Software Engineering, 1995, Addison-Wesley) characterized this necessity as the requirements uncertainly principle:

For a new software system, the requirements will not be completely known until after the users have used it.

- Return to top -

 

Focus
"If you don't know where you're going,  you might end up somewhere else."
Yogi Berra as quoted by Thomas C. Redman in the book Data Quality for the Information Age, Artech House, Inc., 1996

It is the reality that many (most?) software projects end up late and over budget. And a dismayingly number of custom projects are terminated prior to completion. One reason is that without focus, the costs start slowly, then continue on and on as requirements change. In other words, the project has no focus, no direction.

As a developer, I can't project schedules or costs to reach a moving target. It is accepted all the requirements will not be identified at the start of a project because of the requirements uncertainty principle (see Reason 2, End-user Participation).

But the primary requirement for focus, is to keep the project on schedule and within budget. 

Focus must be attained early and maintained by reporting methods and project reviews.
- Return to top -

 

Developer understands ...
Until and unless the developer has a reasonable grasp of your business in general, the chances for a successful project are dim. As a client, you should be willing to spend the time necessary to build this understanding. Not only will this allow the developer to make useful suggestions and identify missing requirements, it invests the developer with a commitment to the project.

Surveys of businesses that use outside consultants, rate the consultant's understanding of their (the client's) business above even the technical competence of the consultant. This knowledge can only be gained by the client spending the time, and displaying the required patience, for the developer to gain this overall understanding.


- Return to top -

 

Client understands ...
It is useful to compare the development of  custom software to the building of a custom home. You can't start building until the design is complete. And once construction starts, you - the client - can change your mind as long as you accept the reality that you will have to pay the builder to make the changes. Your original estimates for both total budget (dollars) and completion date will have to be adjusted. 

In other words, most any change is possible, but it costs money and impacts the completion date.

Successful projects are marked by the client achieving an understanding that schedule, cost, and product (i.e. the number of features such as screens, reports, etc) are inter-related:

Add or change the requirements? Change the cost and schedule.

Want to reduce the cost? Reduce the product features.

Want a faster delivery? Reduce the product features. Increase the cost by adding more programmers or pay for overtime.

Clients should think through their requirements and decide upon the minimum level of functionality for the new software that will - when the software is running - provide a useful, measurable business benefit. Implement all the must-have features first. The idea is to limit your risk (time and money) while you gain an understanding of the software development process.


- Return to top -


Project management
The more complex the project, the smaller the percentage of total project time that is devoted to coding (i.e. a programmer writing software code). Successful projects are managed along relatively classical lines: schedules, budgets, forecasts,  status reports, a structured change order process, etc.

But developing new, custom software applications still has a significant creative component. This means that project schedules (time and cost) are estimates. Certainly as the project proceeds, the project schedule should stabilize. If it doesn't, that is an indication of trouble.

Ultimately, we can't avoid the wisdom of one of my experienced clients who stated his development philosophy as a question,  "Why is it that things always take as long as they do."  Translation, software development is a profession, and a science, just not an exact science.

To account for the uncertainly of the process, I make estimates as ranges, for example 175 - 250 hours And that forecast is made after the requirements are known.

My experience is that the first (two part) question from a new client is "How much and when?" My answer, "I don't know ... yet."  Once the requirements are known, forecasts are possible and project management practices offer you - the client - a reasonable chance that the forecasts will be met.

Generally, a developer cannot provide a fixed price estimate, especially for a new client where there is not an existing working relationship. However, some projects are small enough such that the developer can provide a fixed-price bid, but this requires both the developer and client agree on a fixed scope of work. 

But most projects are best managed by limiting the initial scope and going through the development process. As a client, this will provide you the experience necessary to make informed decisions about future effort.
- Return to top -

 

Technical competence
Many clients focus on the hourly rate of the programmer/developer. They decide that a programmer is "worth" x dollars per hour. Any programmer. All programmers. One rate.

Yet consider: "... study after study has found that the productivity of individual programmers with similar levels of experience does indeed vary by a factor of at least 10 to 1." (Steve McConnell, Rapid Development, Microsoft Press, 1996)

In my opinion, the proper focus is success/failure. Which is to say, you should focus on the overall competence and experience of the developer. If you have a serious business need, then you need to consider carefully whether a purely technical approach will translate your business needs into an application (and business process) that meets your goals. While technical competence is necessary, it is not a sufficient condition for successful projects. The management and communication skills of the developer, are oftentimes the key indicators of a successful project.
- Return to top -

 

 

Shared reality
Reason 4 says that the developer needs to understand your business. And Reason 5 says that you need to understand something about the development process. These two only work if blended into a shared reality. It is not realistic that the developer will ever fully understand your business, nor is it likely that you will become an expert in software development.

But what is necessary for successful projects,  is that the client and developer find (or create) an area where they both have a shared agreement on principles. For example, the client needs to understand that changes to the requirements impact the project cost and schedule. That's the nature of software development.

On the other hand, the developer should understand that if some software feature is "neat" or "fun to do" or "elegant", but useless to the client, then the developer is wasting the client's money to spend time on that feature.

It is my belief, that successful projects occur when this shared reality exists. You have to work to build it early in the process. And it must be used with a flexible viewpoint. The client should exercise patience and keep an open mind when a developer presents technical considerations. And the developer should listen carefully when the client explains what they need - and what they don't need - in a custom application.


- Return to top -

 

 

Communications
"Don't know what you don't know."
"It is acceptable - even mandatory - to articulate your ignorance.."
(Jim McCarthy, Dynamics of Software Development, Microsoft Press, 1995)

Projects succeed when there is an open flow of communications. The client should recognize that they are unlikely to have programming skills equal to that of someone who develops projects as a full-time profession.

And the developer needs to understand that projects are done at the client's expense because the client has a business need. Projects are not done so that the developer can demonstrate that they are a great programmer.

These two inclinations need to be mitigated through open communications so that a mutual respect and understanding exists and the project can succeed.


- Return to top -

 

 

 

On time payments
If you are a client and having a project done by a large consulting firm, then this probably doesn't apply. The people assigned to your project are far removed from the issues of invoicing and accounts receivable for their firm.

However, much of the creativity and excellence of programming as a profession resides in smaller firms,  and solo practitioners. Nothing sours a relationship faster - in my opinion and experience - than a client that is slow to pay or gives the appearance that they are managing the project by the timing of payments.

If you are a business owner, it is unlikely that if you are dissatisfied with one of your employees, that you withhold the employees paycheck to show your displeasure. It is more likely that you discuss your concerns with the employee with the goal of making adjustments or gaining understanding.

It should be the same with your developer or consulting firm. This is another reason that open communications are important. If the project is being managed carefully with project management principles, there should be few surprises.

My recommendation is that new projects be done in small enough pieces to control and manage risk. 


-- Return to top -

Home Page