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
4. Developer has understanding of the client's business
5. Client has understanding of the development process
7. Technical competence and maturity of the developer
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,
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.
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.
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.
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.
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.
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.