- Antipattern Name: Project Mismanagemen
- Also Known As: Humpty Dumpt
- Most Frequent Scale: Enterpris
- Refactored Solution Name: Risk Management
- Refactored Solution Type: Process and Role
- Root Causes: Responsibility (the universal cause)
- Unbalanced Forces: Management of Risk (the universal force)
- Anecdotal Evidence:
“What went wrong? Everything was fine and then suddenly… KABOOM!”
This AntiPattern concerns the monitoring and controlling of software projects. The timeframe for this occurs after planning activities, and during the actual analysis, design, construction, and testing of the software system. Project mismanagement involves mistakes made in the day to day running of a project, assuming planning errors (such as Death By Planning) have not been made.
Running a project is as complex an activity as creating the project plan, and developing software is as complex as building skyscrapers, involving as many steps and processes, including checks and balances. Often, key activities are overlooked or minimized.
These include technical planning (architecture) and quality-control activities (inspection and test). In particular, basic mistakes include: inadequate architecture definition, insufficient code review (software inspection), and inadequate test coverage.
Under the test umbrella, several phases are needed, but often minimized: unit, integration, and system testing. Simple integration testing comprises basic checking of unit-tested components for interoperability. Full integration testing checks all known success paths and error states.
Architecture establishes the detailed technology plan for the project, including the criteria for inspection and testing. When an inadequate architecture is defined, there is insufficient basis for checking the design during the inspection and testing phases. When testing is performed, the software modules may be integrated according the architecture, but are not able to interoperate according to the application’s needs.
Symptoms And Consequences
- The design is difficult to implement due to lack of an architectural strategy.
- Code reviews and inspections happen infrequently and add minimal value.
- The test design requires extra effort and guesswork because the behavioral guidelines for the system are inadequately defined.
- In the integration and system testing phases, there is much project “thrashing” due to a large number of defects that should have been eliminated in earlier phases such as architecture, design, inspection, and unit testing.
- Defect reports escalate toward the end of the development and delivery/acceptance phases.
- An inadequate architecture does not define the technical criteria for inspection, testing, integration, and interoperability.
- Code reviews and software inspections do not evaluate design defects, which then must be addressed in more expensive phases such as acceptance testing.
- Insufficient test suites check basic integration needs, but do not address full interoperability needs for the application.
- All of the preceding factors indicate ineffective risk management, which can be traced to the professional practices of the architect, designers, and management.
There should never be any exceptions to the Project Mismanagement AntiPattern.
Proper risk management is an effective means of resolving predictable symptoms and consequences of the Project Mismanagement AntiPattern. Risks are categorized in several useful ways: managerial, common project failure points , and quality. It’s necessary to understand these categories in order to better qualify the risks.
These risks are primarily caused and resolved by corporate management:
- Processes. An end-to-end definition of product development.
- Roles. The specific responsibilities for implementation of the processes.
Common Project Failure Points
These key project risks are based upon twenty-three risk drivers:
- Cost overruns.
- Premature termination of project.
- Development of the wrong product.
- Technical failure.
- Program and project management. The effectiveness of the planning and control process.
- Product identification. The accuracy of the problem definition.
- Architecture definition. The specification of a design and coding strategy.
- Solution design. The ability to deliver a consistent and optimized code specification that fully supports the solution.
- Solution implementation (coding). The ability to produce an accurate code implementation of the design, which functions in the expected manner.
- Solution validation (testing). The proof that the implemented solution fully meets the problem requirements.
- Product support. The ongoing ability to maintain and enhance a released product.
Often, a theme of risk management is the absence of a common understanding, resulting in an inconsistent view of development, which leads to the risk of the solution not meeting the scope of the problem requirements. A company must understand its software developments across all sites and all projects. Every project must share common knowledge about its development.
Ideally, all (or most) development staff on a project will have a reasonable, overall comprehension of the problem requirements and the intended solution. Unfortunately, often this is not the case, leading to one or more of these failings:
- Missed functionality. One or more component services were never built because there was no shared view of how all of the components would interact on the delivery platform.
- Incorrect functionality. Some component does not perform the full functionality required because its use was never shared by developers with users (other developers).
- Overfunctionality. The requirements were never clearly understood and “the devil in the details” was never extricated. This leads to software development under “good intentions,” without any requirement or need ever being clearly established.
- Code modules will interface but not fully interoperate. There was no definition of the threads of control across system and module boundaries.
The refactored solution entails activities at the architectural and design stages of development. At the architecture level, the dependencies between modules must be defined. This includes the assignment of responsibilities that define the interdependence between modules and the partitioning of the system’s functionality. At the design level, the threads of control (use cases) across modules must be defined. This includes all of the successful use cases as well as defined error states.
A formal risk management activity is one way to document and plan for risk mitigation. Formal risk management entails the identification and documentation of project risks, usually in a tabular format, which includes columns for risk severity, risk description, and risk mitigation.
Risk management plans are often produced with the formal documentation of projects, but are rarely translated into funded project activities. It is important to prioritize the project risks and budget research in risk-mitigation activities that represent critical points of failure.
Another variation, a run-ahead team, is often employed to investigate the capabilities of new products and the compatibility of technologies. The run-ahead team creates prototypes that resemble the target architecture of the system, using the primary technologies or technical backups.
The run-ahead team also identifies any technology shortcomings and investigates workaround strategies. The team then educates the rest of the project staff on the new technology, thereby shortening learning curves. Finally, the run-ahead team must precede the main development activity by one to three months. Otherwise, the main project may be delayed waiting for the results of the run-ahead research.
A software development does not manage it’s code delivery. The development teams are left to their own devices as to how to get from design to delivery. This means that they each have to deal with quality and process issues via self-derived mechanisms and manage their own activities. The risk becomes unacceptable code through lack of adherence to:
- Coding standards (including traceability to the design)
- Code reviews
- Test planning
- Unit testing
- API testing
- Integration testing
- Feature testing
- Program documentation
The risk manifests itself as poorly documented code that has been largely untested and does not integrate, nor fully meet the requirements.
The appointment of a new project manager results in quality/process improvements. The improvements are incremental and are actively owned by the teams through a series of facilitated “lookback” sessions to identify problems and issues, and then the creation of emissary groups to address them via incremental process improvements.
Each emissary group consists of a facilitator from product support and a development team owner (for each team) for that part of the process:
Each emissary group team member is responsible for:
- Refining the specific process.
- Educating their team.
- Providing subjective assessment of the team’s implementation of the specific process and the quality of it’s deliverables.
- Liaising with other emissaries to maintain a consistent standard of process implementation and problem resolution.
Within six months each process had been incrementally refined several times and each team had implemented each process at least once. The improvements were major reductions (over 50%) in:
- Code defects
- Documentation defects
- Untested code
A variation of the Smoke and Mirrors mini-AntiPattern describes the incorporation of technical backups into the project plan and activities. This is an important complement to risk management, and mitigates key strategic errors introduced by Project Mismanagement.
Brad Appleton presents an excellent design pattern language for improving software development processes in his paper on process improvement Implementing process improvement is a key element in resolving project mismanagement.
|This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License|