Managing Large Projects (Part3)

Real-time Planning and Control

This technique is counter-intuitive. Many organizations approach large projects with a belief that the more levels of management involved in the project and the more rigorous the reporting system, the more likely the project will succeed. 

Bureaucracy is the cancer of large projects.

Our company and organizations with a proven track record of delivering super-large projects such as Microsoft has proven that to effectively manage a large project radical management techniques are required.

A specific example of this is the concept of real-time planning.

In a large project, there will be many inter-related sub-projects and multiple related projects in other areas of the organization. Even a small schedule slip or scope change on one sub-project could have complex "ripple-effects" for other projects. 

It is mandatory that any change in one project be communicated as quickly as possible to the related projects. A delay of one week could be catastrophic. Our group has seen organizations where the time for a message to move between one project and another project or a project manager and his or her sponsor can exceed 4 weeks. Imagine having a human body where the time between the eyes seeing an approaching car and the brain registering the situation and issuing commands for muscles to begin the process of running took one day!

Fast and open feedback loops between all levels is a critical management issue for large projects.

Real-time planning involves daily reviews of all projects and project status by all project managers involved in the project. Our group deployed this technique on a project involved in integrating two large banks. For the initial planning and quick-win phase of 3 months, 26 project managers, the Project Director and the Sponsor met every day at 8.30 am to ensure a maximum of cross-project communication. Microsoft deploys a similar technique including daily builds and integration of the software written by over 500 people.

Project Team Structure and Organization

Clearly the scenario for large projects is one of a project management team with a number of sub-project teams consisting of business professionals, computer professionals, policy and product specialists, clerical support and computer specialists (data-base, communications, etc).

While each sub-project may have its own project manager, the project management team would be responsible for the total project. The central project management team could also include the project-resident technical specialists and the clerical support staff. In other words, the central project management team would be the project's resource centre for specialist functions. This would be in addition to the normal Computer Group specialist areas.

Each sub-project team would be comprised of business and computer professionals working on the component of the overall system being developed by the sub-project. As is now generally accepted, business professionals from the organization areas involved in the project would be full-time members of the project team and, in many cases, senior business professionals would be performing the project management functions.

What is mandatory in large project is to minimize the hierarchy and maximize the communication. As discussed earlier, this may appear counter-intuitive, the history of large projects (see Attachment) indicates a common pattern of many layers of management being involved in making even the most simple of project decisions. The result of this is massive delays in decision-making, substantial filtering and distortion of project communication and, in effect, collapse of the project management system for which the management hierarchy was formed to control and manage.

In essence, the larger the project, the shorter the communication lines must be to ensure fast-feedback through the project management system to all sub-project teams.

Ideally, a large project should have no more than two levels of management between the sub-project team and the Steering Committee. This can easily be accomplished through the use of Likert's (1961) Linking-pin structure. As shown in Figure 2, this structure involves each sub-project team being represented on the project management team and the project management team being directly involved in the Steering Committee team. In other words, the Steering Committee has the project manager as a full-time member and certain team members are involved in two teams (either horizontally or vertically) as the linking-pin. 

Fig. 3 - Project team structure (Option 1)

An alternative model of project organization is to create a totally flat reporting structure. In Option 2, the Project Sponsor, Programme Director and all the Project Managers of each involved project form a virtual team.

Using the real-time planning concept, the Project Management Team meets daily (initially) and weekly (once the projects have been initialized and and in full development. In these meetings, risk management, issues management, project resourcing and other planning concerns are dealt with in a non-bureaucratic structure.

Fig. 4 - Project team structure (Option 2)

A Programme Office must be created to support the Project Director and the Project Managers. It is important to mote the emphasis is on support not control. Roles typical of a state-of-the-art Programme Office include:

Further, the use of an electronic mail system dedicated to the project team would be a valuable aid in ensuring that critical messages could be sent to all relevant people. Most electronic mail systems also include an "action-prompt" feature, which would ensure that critical messages were responded to within in an agreed time frame.

Project Development Strategies

A system or project development strategy is the overall partitioning of the project and the high-level sequencing of sub-projects. Robert Melichar of IBM articulated three primary development strategies. 

The monolithic, waterfall, or classic strategy where all tasks associated with a system development phase (e.g. analysis) are completed before any of the tasks involved with subsequent phases are planned, scheduled or undertaken; the version or release strategy where after initial systems analysis or modeling, the product being developed is divided into sub-products and each sub-product is developed as a quasi-independent sub-project. There are two "sub" strategies associated with the release strategy. The first is sequential release where one sub-project is completed before the next sub-project is started. The second sub-strategy is concurrent release where the sub-projects are developed by separate teams often being scheduled in parallel.

The final strategy is the evolutionary or fast track strategy where the approach is to develop a full production version of the product as quickly as possible. The result would be an undocumented, inefficient and "dirty" production system which could be used while the fast-track development cycle is repeated to stabilize, add or delete features based on the use of the production system. This strategy is the most commonly used in other industries for large or high-risk projects ( e.g. the new Parliament House and the Darling Harbour are using this strategy.

However, it is probably more practical to use a combination of all strategies for large projects. For example, the overall system development strategy for large project would be a concurrent release strategy with some of the high-risk sub-projects being developed via fast-tracking while more low-risk sub-projects could be broken into sub-releases and developed using the monolithic strategy.

Fig. 4 - Typical large project development strategy

The use of multiple strategies within multiple releases adds further support to the requirement for vigorous and formal project management techniques. Apart from the sheer complexity of scheduling many people to many tasks, the project management system is vital in ensuring that changes in one sub-project (release) do not impact on another sub-project.

Quality Assurance

While formal quality assurance techniques (Technical Reviews, walkthroughs and QA Groups) are apparently only partially implemented in the computing areas of Australian companies, the need for Total Quality Assurance is essential in large projects.

As Capers Jones' (op cit) research shows, the scale of effect issues discussed earlier in this paper has a significant impact in the area of defects in large projects. Simply, the level of defects per line of code is 200% higher for large projects than for small projects and up to 400% higher than for super-large projects.

This has serious implications for the intrinsic quality of the product and the higher level of defect implicit in large projects adds an additional factor to the potential degradation of the requirements through analysis, data-modeling, design, documentation and coding defects. Capers Jones (op cit) has found that the detection and removal of defects throughout all phases of the system development life-cycle can account for 40% of the total development effort for large projects. In other words, without an effective Quality Assurance component, defects can account for around $2,000,000 of a typical large project's development cost!

Apart from the simple issue of defects, the relatively high incident of defect associated with large projects has a major impact on the project management issues. The "ripple effect" of defects passing between dependant project tasks is one of the biggest causes of poor estimation and project slippage. 

The solution to this issue is to enforce formal quality assurance techniques (Technical Reviews, Inspections or walkthroughs) at the end of each task. As documented by Sprouster (1984) and Weinberg and Freedman (op cit), it is cheaper and more effective to perform quality assurance in short, sharp sessions conducted by the development teams rather than the prevailing approach in computing (and many other industries - see Sprouster) of large QA sessions conducted at the end of a number of tasks (sub-phase or phase reviews). However, in super-large projects, quality assurance also needs to involve many additional external groups when compared to smaller projects.

Finally, as discussed earlier a feature of large projects is the use of staggered multiple releases of sub-project deliverables into the production environment. While this is a essential feature of the release and fast-track strategies it presents a special problem in the area of production support and defect repair.

It would be typical for the initial production releases of the project to be continually developed or enhanced as well as undergoing the normal post-production defect repair cycle. As a result, changes will be made to production data, data structures, function and documentation. These changes may have a flow-on to the releases still in development. For example, a data structure may be shared between a production release and an in-development release. These changes must be reviewed not only by the production support teams but also by the development teams working on related releases. In other words, production support QA must be shared by both development and production support teams. As a result, it is essential in large projects for the development and production support teams to be fully integrated and co-located to minimize communication breakdowns.

copyright: thomsett INTERNATIONAL 2006 | contact