|
Home Our Company Public Workshop Schedule In-house Delivery and Consulting Workshop Descriptions Site Map Articles |
Managing Large Projects (Part4)
Support tools and technology
Substantial development has occurred over the past few years in the area of automated development support tools (particularly in personal computer- based tools). The development and support of large projects would require dedicated access to the following tools:
| CASE (Computer Aided Software Engineering) | these tools are currently in a period of rapid development. However, all of the widely-implemented products (I.E. Workbench., Excelerator, etc,) provide the ability to record data-models, data-flow diagrams and design diagrams using graphic interfaces. CASE-type products will reduce the effort required to document and maintain the various technical specifications across the various sub-project teams; |
| Data Dictionary | it is vital that the data being developed in the project is recorded in a centralized manner. Given that data is shared across the various sub-projects (releases), any person on the team must be able to determine the logical and physical characteristics of the project's data and, in particular, which data is used in which sub-project; |
| Desk-top Publishing | Capers Jones (op cit) has data, which shows that documentation and paper-work consumes 30% of a large project's effort (compared with 10% for smaller projects). Just as CASE tools will assist in reducing the effort on documenting the technical diagrams, the use of desk-top publishing tools will assist in the production of business professional and operations manuals, forms production and general system documentation; |
| Electronic mail/ Groupware system | as has been discussed earlier, a dedicated electronic mail or Groupware system could facilitate the intra-project communication. Given the need for communication across many sub-teams and related specialist and management areas, this technology could provide a quick, efficient and auditable mechanism for recording and transmitting information; |
| Intranet/Internet | these technologies are essential for fast and relatively cheap communication with the large number of stakeholders associated with large projects. The development of a Project Web Site which contains the Business Case, project status reports and so on is a major advantage in stakeholder communications; |
| Advanced phone system | the author's research indicates that the typical project person can lose up to 20% of a day in the activities of answering other project members' phones, taking messages and locating that person. The use of a switchable phone system (or answering machines) where each team-member can switch their phone to a centralized message centre staffed by a clerical support person can lead to substantial gains in productive hours of work per day. In addition, the use of phone-conferencing would assist the electronic mail system in facilitating project team communication; and |
| Meeting software | Products such as Zing which enable the gathering and processing of many ideas from project planning sessions. |
Other support issues include application development and prototyping tools, automated testing and debugging tools, physical office design, rooms for walkthroughs and team meetings, access to technical libraries and so on.
Stakeholder Management
A stakeholder is a group, organization or person outside the direct organizational control of the project manager. In a small project, the stakeholders would typically include the project sponsor, direct business users of the project's deliverables, operations areas and perhaps some internal or external software development and data administration consultants. In super-large projects, the stakeholder community exhibits the same dis-economy of scale as in the effort required for development.
In a super-large project, the stakeholders would include would include groups both within the organization such as Data Administration, Network, Operations, multiple client groups and other dependant or interdependent projects and, in most cases, areas outside the organization such as vendors, other companies, unions, government and other major groups. For example, in one project with which the author was involved over 60 external stakeholder groups were identified. This means that much of the project management effort (in excess of 50%) will be devoted to managing the stakeholder relationships in these types of projects. Further, the quality assurance processes such as reviews would need to accommodate the requirement for multiple stakeholder reviews. For example, in a small project, a review of functional requirements may involve 5 -7 people and take 2 hours. In a super-large project, a review of functional requirements may involve 20 - 30 people over a period of 2 days. Clearly, review techniques designed for small group review need to be modified for super-large projects.
The use of the linking-pin as discussed earlier is another vital part of stakeholder management. In particular, linking-pins between the project and related projects ensure that the detailed technical issues such as common function, data, design impacts and so on are managed at the appropriate level.
Team building and maintenance
Because of the long duration of super-large projects, team dynamics are considerably different than those in smaller projects. In three super-large projects with which the author has been involved in over the past three years, the team membership changed completely over the time for development. In one project, the only original team member left upon final delivery was a contractor!
Because of the inevitable turnover in super-large project and other concerns covered in this paper such as the need for highly-disciplined project management, multiple external relations and large team size, the issue of team building and maintenance is one of the key issues in super-large projects. As discussed by Constantine (1995) and Thomsett (op cit), most computing organizations have failed to develop and implement effective models of teams and the processes of team-formation and building are left to random selection based on technical skills and resource availability only. In the case of small projects, a randomly-formed team may manage to produce the required system without having to face the morale and motivation crises that are a documented part of large projects. However, the team dynamics of super-large projects are such that there is a need to ensure that the requisite team roles as described by Thomsett and Constantine are present and that the appropriate team maintenance and support mechanisms are build into the project.
Super-large projects require the deliberate and structured formation of a project culture that provides a common vision for the team members. The project vision is a vehicle for ensuring that the project's objectives and values are linked into the corporate objectives while providing a micro-climate or culture that will sustain the project as team members leave and join throughout its life. In the super-large projects with which the author has been consulting with over the past three years this project culture is manifest in the project management documentation (scope, objectives, quality and so on) as well as in "softer" concepts such as a project logo, project marketing material (brochures, portfolios), formal project induction programmes and regular (usually every 3 months) "time-outs" which combine formal planning and team building exercises.
Development and maintenance of the project culture is a key project management role in super-large projects.
Change-control Procedures
Probably the single most important feature of large projects is the previously mentioned scale-of-effect (Fig. 1). There is a non-linear growth and effort pattern for large projects.
Fig. 6 - Impact of changes
Using the Lines-of-Code in Fig.6, a change in initial requirements resulting in the need to provide an additional 5,000 LOC on a system of base-size of 25,000 LOC would require in the order of an additional 200 - 300 work-hours of effort. To add the same requirement of 5,000 LOC to a large project of 125,000 LOC would require in the order of an additional 6000 work-hours plus!
This leads to the formulation of Rob's Rule of Large Projects:
For large projects, there is no such thing as a small change.
Capers Jones (op cit) refers to another I.B.M. study that indicates that the typical behavior of all information system projects is an expansion of requirements and effort by 50% over the projects development life. Given the scale-of-effect problem, the control of changes in large projects becomes mandatory.
It is normal for a large project to change monthly.
In effect, any change to the project (requirements, costs, effort, staffing and so on) should be treated as a mandatory "freeze" point.
The project or sub-project should be temporarily stopped and a meeting involving business professionals, project leaders and managers, client groups, relevant specialist groups and the team be convened to evaluate the impact on the sub-project and the total project of the change-request. Should the change impact agreed costs, schedules, requirements or impact other sub-projects, then the change should be forwarded to the Steering Committee for approval prior to implementing the change.
Clearly, there will be some changes which can be accommodated within the sub-project manager's scope of control and authority but, all changes to the initial requirements and schedules should be formally documented and reviewed at the regular project manager meetings.
Finally, most change-control procedures are designed to accommodate externally-generated changes. In a typical project there are probably as many internally-generated changes resulting from poor estimation, staff turnover, defect repair and so on. The change-control system must also accommodate these internal changes as well.
Project Agreements or Contracts
As discussed earlier, all large projects necessitate the use of multiple teams that cross traditional inter- and intra-organizational boundaries.
It would be typical for a large project to involve 10 or more separate teams - business professionals, computer professionals, specialist groups, unions, contractors, multiple vendors and so on. In many cases, these teams are not in the direct scope of control of the overall project manager. Often, it would be the case that key tasks on the project's critical path would be under the control of an outside "sub-contracted" area.
As a result, the development and commitment to deliverables, tasks and deadlines involving teams outside the direct control of the project manager must be negotiated and formalized prior to the overall commitment by the project manager and the team to that specific part of the project. For example, should the project manager require consulting and or direct assistance from the Network Design group, the project manager would review the schedule and the level of support required with the Network Design manager. Once an agreed schedule was negotiated, the Network Manager would be required to sign a formal contract to the effect that he or she was prepared to commit to the project's requirements.
The formalizing of what is usually an informal review process is critical in large projects as it ensures that the project manager has considered the broader organizational support required and that the other areas are involved in developing a realistic schedule that recognizes their other on-going work. Of course, all project contracts would be reviewed by the Steering Committee prior to approving the particular component of the project development cycle.