Very few projects go as planned, however, projects that fail often follow a pattern.  Normally projects fail due to issues  with:

1. Personnel - These issues range from wrong skill sets to bad work environments.
   See prior newsletter: Common Software Project Management Mistakes - Personnel Issues

2. Project Management - These issues relate to improper processes and techniques for managing projects.
   See prior newsletter: Common Software Project Management Mistakes - Project Management Issues

3. Application - These are issues with the application itself.

4. Technology - These are issues with the technology chosen for the application.

In this newsletter, we will focus on Application issues, we will cover the other issues in subsequent newsletters.  Below are the common project management mistakes relating to the Application:

1. Lack of Reusability - To complete projects on-time and on-budget, your chief architect must create an architecture that is reusable and easy to maintain.  About 10 years ago, I worked on a project that had been architected by a third-party company.  The third-party company had already collected all customer requirements and that third-party company decided to quit.  I was brought in to rescue the project, as the new chief architect.  After reviewing the screen layouts and software architecture, I quickly discovered that it had about 150 screens that could be written using one reusable screen and 1 reusable table.  However, the design called for each screen/table to be written separately, each with it's own design.  This was problematic because it would take much more time to create 150 screens than 1 screen and if small changes needed to be made, you had to change 150 screens instead of 1. After meeting with the project manager, they refused to change the design and architecture of the system, so I told them I was the wrong person for the job.  They found another less experienced architect that stuck with the original design.  The project was delivered 2 years late, cost 3 times the original budget and the end-client eventually sued the firm that created it.
   Learn More about creating Detailed Designs...

2. Lack of Auditing -  Every application should contain auditing that shows each record that is changed, who it is changed by, the date/time the change was made and what the value of the item was before and after the change.  Likewise, all fatal errors that occur should be written to an Error Log and automatically be sent via email to the support team for resolution.
   Example of an Audit Trail    Example of an Error Log

3. Gold-Plating -  Gold-Plating is the process of building bells and whistles into an application that were not called out by the end-client.  Normally, there are 2 types of gold-plating activities:
   
   A) Specification Gold-Plating - First, project managers and business analysts are tempted to add additional bells and whistles to a requirement, even though it was not asked for by the client and may not add an "real" value to the product. 
   
   B) Programmer Gold-Plating - Another type of gold-plating is done by the programmers.  A programmer may have a specification and may decide to add some extra programming bells and whistles that were not asked for. 
   
   C) Example - Here is an example.  The client asks for a simple file upload system, as the client would like to upload small documents to a web site.  The business analyst decides that it would be neat to give the client a progress meter as the file uploads and also a way to pause an upload and resume it later.  The client's intent was to upload very small files, so this feature is simply not needed.  By adding this feature to the specification, the cost and effort of the project was increased.  Once the programmer receives the specification, they decide that it would be really cool to provide a drag-and-drop interface, so they purchase a 3rd party product to allow this and implement this.  This adds 2 days to the original schedule, causing the product to be delivered late and over budget.
   Learn More about Requirements Scrubbing...

4. Feature Creep - Another common mistake is to allow feature creep, which simply means adding features that were not in the original design without adjusting the schedule.
   
   Example: The client casually calls and says the export feature is working as designed, exporting data to CSV file as per the original specification.  Then they say, "it would be great if it could export directly to Excel with formatted headers".  To the business analyst, it sounds like a reasonable request, so they speak with the programmer and they decide to do it.  By implementing the new feature, the export feature was delayed by 4 hours, impacting the schedule.  Then the documentation team learned about it, and had to make changes to the documentation, which caused a 1 hour delay in documentation.  Then the testing team learned about it and had to add additional test cases to handle the Excel export, adding 1 hour of delay to the testing plan.  Last, the support team learned about it and had to support this feature on different versions of Excel (95/2000/etc), adding additional support hours.  From this small change, came significant schedule impact.
   Learn More about Change Control...

5. Bleeding Edge Technology - Finally, another common mistake is relying on bleeding edge technology. For example, let's assume that you have a requirement that requires a robust reporting system, accessible from the web.  You may be tempted to dive into new technology (you find a beta version of a reporting engine that sounds very interesting), and you may experience issues with adopting a technology that is unproved and not yet mature.  However, if you go with a product that has been proven over the years (like Crystal Reports in this example), you will most likely have much better success because the technology is time-proven. 
   Learn More about Risk Management...