Bang for the Buck.  The key project management issues discussed include estimating, requirements analysis, selective standards, cognizant programmers, code inspection, quality, and changing requirements.  The issues presented are relatively easy to implement and worth the minimum extra effort to increase the probability of a successful project.

The key issues described only bring you to a reasonable level of risk control.  There is much more needed to decrease the risk of missing schedules and maintenance nightmares.  The short descriptions do not do justice to the issues.  This document is intended to provide a starting point in understanding the risk reduction factors and how they should be tailored to the unique requirements of your organization.

Tradeoffs.  Project planning is an exercise in risk management.  The target:  lower risk without unnecessarily increasing cost.  The balance is difficult and the Project Manager must struggle with the tradeoffs when deciding on the processes to be used for each project. The following techniques and recommendations are the minimum to include in your project plan and implementation processes.  (Note:  Obviously late projects increase cost or even lead to cancelled projects.  The extra cost of implementing risk control is low compared to the consequences of overrun / cancelled projects.) 

Personnel, Politics & Stakeholders.  There is no substitute for having the very best project managers, group leaders, analysts, programmers, and quality assurance personnel. Even more important is the political environment that project personnel must work within.  Management and associated groups that are fully supportive of development projects is critical for project success.  There are many companies where the politics are so bad as to ensure that projects are always late or fail. Project Managers must understand organization dynamics and adjust estimates appropriately. 

You must ensure that all stakeholders in the project have a vested interest in the success of the project.  Stakeholders include higher management, organizations providing services to the project, customer representatives.  This is simple:  made a conscious attempt to speak to them often, share documentation, show progress demonstrations, solicit opinions, and anything you can to have them participate and buy into the project.

Another disastrous situation is using support personnel for development tasks.  Inevitability the projects will be overrun.  Priority support problems always come first and the extent of the support cannot be controlled.  Never use support personnel on development projects unless you utilize them part time on the project and they are NOT assigned to critical timeline tasks.

Standards.  When standards are not required by your customer or your organization you must establish your own software development process standards.  There are minimum standards required for every project: project plans, status reports, requirement specification, system specification, software design specification, coding standards, code inspection (walkthroughs), testing (unit, integration, system, acceptance), and configuration control.  Projects may require additional standards, such as detailed design and unit testing inspections, depending on the target system environment and the complexity of the project.  It is obvious that for a life threatening environment you will need to establish and control a maximum level of standards.  The other extreme is a one-time use program (e.g. conversion utility) requiring minimum standards.  Note:  I have seen very few one-time use programs that are really used only one time!!!

Requirement Analysis.  Yogi said it best, “You need to know where you are going before you can get there”. You must completely understand the requirements and their implementation implications.  Write them down in detail and have your customer sign-off on them.  The requirements should include user interfaces, processing rules, detailed algorithms (at a minimum the difficult ones), error processing, system redundancy & recovery, system architecture, database implications, interfaces to external systems, and anything else that will cause project overruns if not completely defined.  There is no substitute for comprehensive requirements signed off by your project manager and customer. 

Fast prototyping is highly recommended to ensure that the requirements are understood by all parties.  Always include this phase whenever reasonable, especially for human interface intensive projects.  Be sure that the fast prototype is not throw-away software but the basis for the remaining software to be developed.

Design.  The level of design detail depends on your project.  The minimum design is a systems top-level design.  This specification defines in detail the following: software & data hierarchy, difficult and critical algorithms, external and internal interfaces, database elements, testing criteria (unit, integration, system, and acceptance).  There may be a separate system specification depending on the complexity of the system.

Estimating.  Estimating is a continuum based on the information available at the time of doing the estimate. Estimates without detailed requirements are at best budgetary estimates useful to determining the scope of a project.  The error factor is as high as 50-100%. Estimates after a thorough requirements analysis have a risk factor of 25-35%. After baseline (top level) design the risk factor should be between 10-20%. These risk factors assume that your personnel is available as needed, the sign-off process is reasonable, your organization supports the development effort, and the requirements are not changing.

The bottom line in estimating is that there is always a risk factor involved until you finish the project!  State the estimates with the associated risk percentages. If you really need to provide an estimate that is 99% accurate then add in the error factors to your estimate.

There is a large body of literature on estimating practices.  The estimation practices are a valuable tool and will yield better estimates.  Use whatever estimation techniques make sense to you.  Just about any one of them will improve your estimation process.

Commitment of the personnel doing the implementation is critical to meeting schedules.  Require your entire team to estimate each subsystem. Try to understand large discrepancies between estimates and determine a reasonable estimate everyone can agree on. 

Discuss estimates for each task with the programmer assigned to the task. Ask the programmer to estimate the time needed for the task.  If the estimate differs from yours find out why and adjust the estimate.  Always give the programmer the benefit of the doubt.   The programmer now has no excuse for not meeting schedule.  Hold your programmers to at least an 80% success rate.  This is an important metric for performance reviews. 

"It ain't over 'til it's over" (Yogi).  It is critical that everyone understands what “done” means.  This is a bigger problem then it seems.  Be very specific.  For example, “done” means that all process standards are followed without exception. 

It is management’s responsibility to ensure that the programmer does not have excuses for not meeting schedule.  Carefully plan testing resources, code inspection meetings, and anything else that would impact schedules. 

Cognizant Programmer.  It is critical to be able to recover from a loss of personnel on a project.  Programmers are not available for many reasons including sickness, vacation, resignation, transferring out of the department, and for needed for a critical support assignment.  The only way to recover without training a new programmer on the technology used, requirements, design, etc. is to have a programmer standing by.  This programmer is called the Cognizant Programmer. The Cognizant Programmer will devote minimum time to the project.  The Cognizant Programmer will be copied on all project documentation, attend review meetings, attend walkthroughs with the programmer being covered, and generally be able to fill in for the programmer without a large impact to the schedules.  It is also a method of enhancing the technology education of your programmers. In summary, remember what Yogi said about a Cognizant Programmer, "You can observe a lot by watching ".

Code Inspection (Walkthroughs).  Peer review of each section of code yields considerable risk reduction.  The code is reviewed against requirements, design, and standards.  Indirect benefits include educating the programming staff by discussing how the code could be improved and techniques that could be used to improve performance and reliability.  There are many books on how to run a code inspection.  Use the ideas that best suit your organization and include them into your standards.

Testing.  There is no substitute for proper testing at the unit, integration, system and acceptance levels.  Your standards should specify the minimum requirements for each level of testing.  Integration testing should be minimized by doing continuous integration.  Integration toward the end of a project presents to high of a risk of overrunning schedules.  Continual integration exposes interface problems early in the development cycle. 

Another critical concept is to implement the most difficult and the critical code sections first.  If there are going to be problems you want to catch them early in the development cycle.

Maintenance.  The system must be designed with ease of maintenance as a primary objective.  In the system's life cycle maintenance is the highest cost phase.  You will need to easily isolate / fix problems and enhance the system. All successful systems are enhanced to meet changing requirements. Designing for maintenance is a conscious process of selecting appropriate design elements.  When you see complexity for no apparent reason then you will have a maintenance nightmare. With a little creativity unwarranted complexity can be avoided. If it can’t avoid complexity then it must be specially documented for the maintenance programmers.

Quality.  Quality is inherent by the processes used on the project.  It is not a separate task nor something to be scheduled or added in later.  Each phase of the project, including management tasks, contribute to the overall quality or lack of quality of the target system.  For example there is no substitute for not doing proper unit testing.  Code inspections and testing at the end of the project will not catch all coding mistakes.  In fact, errors can occur long after the system has been thoroughly tested and accepted.  Proper adherence to standards and processes will provide the quality required.

Summary.  It is management’s responsibility to meet schedule.  It is never the programmers fault.  To meet schedules risk has to be avoided.  Not all risks can be avoided but the major risks can be controlled.  The concepts described in this paper allow major risk factors to be reduced without undo additional expense.  The end result is an improved success record.

Programming Concepts, Inc. provides software projects management for your organization.  PCI can implement the standards and processes discussed in this paper tailored for your organization.  For more information contact John Petraglia (jpetraglia@programmingconcepts.com).