Topic 1: Advanced project management

Projects revisited

A simple summary of true project attributes might be that projects:
* are goal-oriented
* involve the coordinated undertaking of interrelated specialist activities
* have a single point of integrative responsibility
* are of finite duration, with distinct beginnings and ends
* have a specified budget
* are non-recurrent
* each, to a degree, is unique.

To successfully manage technology projects another dimension is needed for the conceptual map we use to frame and define our projects. The reason is that technology projects involve development activity in some form or other. Even if the project is concerned solely with integrating two existing systems, some elements will require definition, design and production for the first time.

The extra dimension required is the system acquisition lifecycle. In particular, the relationship between the system acquisition lifecycle and the project lifecycle, and how this relationship is likely to be different for each project is important to understand.

The actual model we construct to represent the system acquisition lifecycle can vary in detail, just as the project lifecycle can vary in detail. For example, the system lifecycle follows shows the product lifecycle phases organised into 'acquisition phase' and 'utilisation phase' categories. The phases are:
* Conceptual/Preliminary Design
* Detail Design and Development
* Production and/or Construction
* Product Use, Phase-out, and Disposal.

In the DoD model the management
functions are organised according to the defined product lifecycle phases:
* Concept Refinement Phase
* Technology Development Phase
* System Development and Demonstration Phase
* Production and Deployment Phase
* Operations and Support Phase.

A project may involve one, several, or all the phases of the systems acquisition lifecycle.

Advanced technology projects

We might say that advanced technology projects have the following features:
* a technically complex product
* significant development activity
* require high levels of control and reporting (because of the high risk associated with the development activity, and because the project is likely to have a high company profile for financial, technological, or strategic reasons)
* difficult to assess progress.

Technically complex product
A product or system is a mixture of hardware, software, process and human elements that interact in complex ways.

Significant development activity
The acquisition of any technically complex product, because of the attributes described above, will require significant development effort, even if a key objective is to use existing 'off-the-shelf' systems as far as possible.

Requirement for high levels of control and reporting
The combination of 'newness' (the product or system is being developed because one does not already exist and cannot be bought 'off-the-shelf')—or the mission critical nature of the product or system (for example, e-business system, new combat aircraft, new ticketing machine)—means that the project is always high-risk technically, financially, commercially, and often strategically.

Difficulty in assessing progress
Here we are getting to a critical distinction. In advanced technology projects there is no necessary connection between expenditure and progress. In most other projects there is. In advanced technology projects all of the project budget can have been spent and there may be no useable product.

Where are the project boundaries?
In order to define project scope, a boundary needs to be drawn identifying the 'system' that is being acquired from its external environment. This is not as obvious as it seems. The boundary is rather arbitrary since the system is always part of a larger system, and the purpose of the new system is to deliver new functionality to its user environment. The boundary marks the point where the contractor's responsibility ends and the customer's starts.

What is the project completion point?
The question is easily answered where there is a contract between two separate parties. However, with internal projects, particularly 'business improvement' initiatives, there often can be no clear point where one project stops and another starts.

With the continual upgrade of systems and processes it is often difficult for an organisation to define a meaningful set of acceptance criteria.

What are the project success measures?
This challenge is related to the problem of project boundaries. The design and optimisation of a complex system—the 'architecting' of the system—are inextricably linked to the 'extra-technical' business, social and political imperatives in its environment. Appropriate project acceptance criteria are those which test that the specified functionality and performance have been delivered.

Does the customer know what they want?
Often the customer only knows in general terms what is wanted.

Is the customer asking for what is needed?
By definition, the project team is the solution provider. The customer is not the expert in determining the solution. The customer's clear function and responsibility is to identify a need to be satisfied and the critical parameters within which the solution must fall.

How do we manage the design?
Systems projects are trans-disciplinary projects and, usually, the domain expertise is dispersed both geographically and contractually. Compounding this is the fact that the system is non-existent. It will gradually evolve through the collective intellectual effort of the combined team.

What progress are we making?
Integral to this problem of managing the design discussed above is the problem of distinguishing between expenditure of effort and meaningful progress. It is not enough to work hard on developing the system solution. The evolving solution—the design—has to work.

Does the deliverable satisfy the specified requirements?
Finally, we need structured approaches to ensure that the product delivered can be shown to satisfy the original customer requirements; but we can't afford to wait until the end to find out that it doesn't. For complex systems, consisting as they do of numbers of subsystems, each with comprehensive test programs, it is common to erroneously believe that successful testing of system elements means demonstration of a successful system. By definition, a system is greater than the sum of its subsystems.

The management process needed to manage the problems is a layered one, but has these requirements:
* The selection of a strategy for acquiring the system so that there are clear corporate or program decision points
* A process by which a customer's stated need is translated into a set of requirements and specifications for a system's performance and configuration
* A process by which the configuration is controlled and change is managed
* The identification of the stages in the system's development
* The identification of checkpoints in the design cycle to ensure that objectives are being met and that defects are identified—and corrected as early as possible in order to minimise their impact on the development schedule and on the product's cost and quality
* Methods for predicting system performance to assist in the identification of potential deficiencies in key parameter performance
* A process of enabling requirements traceability all the way through the system decomposition, i.e., from system requirements to item design requirements
* A test and evaluation program that ensures the most cost-effective use of resources and that the final system is validated against the original requirements and specifications.

Integrated management

From our management perspective, systems engineering management is a subset of the wider project management task. A central project management activity is that of making judgements regarding trade-offs between cost, schedule and technical performance in an effort to get the best product at the lowest cost and in the shortest time. If cost, schedule and technical information cannot be drawn together in an integrated way, then these trade-offs cannot be made.

The Work Breakdown Structures (WBS) is a system-oriented breakdown of the scope of a project.

This is not to be confused with an organisational breakdown (organisation chart), a cost breakdown (chart of accounts), price breakdown (price sheet), or any of the other myriad of hierarchical breakdowns possible on a project. As the WBS contains all of the work on a project, and its associated WBS Dictionary contains details of this work, various sections, departments and personnel will look to the WBS for the information that they need to perform their role.

* The WBS primarily defines and decomposes scope.
* The WBS is an input to the other key project management deliverables—schedules, activity descriptions, etc. i.e. it is developed before these other deliverables.
* The WBS can be either lifecycle structured (where Level 2 of the WBS says 'Phase 1', 'Phase 2', etc. and the product tasks are at a lower level in each of these branches of the WBS), or system structured (where the upper levels of the WBS are a system breakdown, and the lower level branches of each component have Phase 1 tasks, followed by Phase 2 tasks, etc)—provided that both the system hierarchy and all of the tasks in all of the phases are included.
* The WBS is used by a range of personnel and is a communications tool.

Each element of the WBS must be owned by one person. One person can own many WBS elements though. This means that we can map every aspect of the WBS to the organisational (breakdown) structure (OBS) to produce a responsibility assignment matrix (RAM). Because we can perform this mapping at all levels down to the cost account level, we can also map all costs for the project to the organisation’s budgets and expenditure codes.

The 'WBS within a WBS' idea introduces another important concept to keep in mind as you work through this unit. Projects may contract out portions of their work to other organisations. These other organisations now have a project to deliver the work they have agreed to. Projects may spawn other projects. There will be projects within projects, teams within teams, deliverables within deliverables.

A key to WBS development is that each WBS element must contain all of the work directly associated with completing that element. This is sometimes referred to as the 100% rule. The top level element must contain 100% of the work, costs, people, deliverables, etc that will be performed on the project.

* there are WBSs within a WBS
* the WBS should contain both the system (deliverables, products, artifacts and components) and lifecycle (phases, stages and sequence) elements
* each element of the WBS is 'owned' by one person
* the WBS contains all of the project scope

When complete, the WBS should:
* have all of the work that needs to be performed within the project
* link to the schedule—where all of these elements are linked to create the timeline of the project
* link to the budget—where all of the costs should be listed and monitored
* link to the organisation structure—where all of the people working on the project should be shown.

Problems with projects

Problems with scope
We know that we need to have scope clearly defined and agreed prior to starting; however, often the reality is different. With internal projects, there is no internal contract that defines scope. Scope is defined in project documentation but loosely acknowledged outside the project. With external contracts, usually the contract signed was a version of fixed-price because no customer is prepared to issue cost-plus contracts.

Problems with schedules
Schedules function in two ways: as static contractual agreements on delivery dates, and as dynamic networks to assist work planning and reporting. However, achieving an integrated schedule that fulfils both these functions is very difficult for most organisations for the following reasons. If it is fully vertically integrated, then perturbations at the bottom produce perturbations at the top. Perturbations at the top are seen by customers who, not being experts in schedules, become nervous and express concern.

Problems with budgets
To have any meaning from a project point of view, the budget must accurately reflect scope and there must be a sense of ownership by those who are to perform to it. To the project manager, the project budget is the thing performance is measured against. They are particularly interested in its relationship to scope. To the financial controller, the budget represents a cashflow profile and is a key
determinant of profit projections. They are uninterested in its relationship to scope. To the chief executive officer, the budget is something between the project owner and whoever has been appointed to do the project. To the project owner, the budget is a problem.

Problems with resources
Resourcing is always a major problem in advanced technology projects. All but a very small minority of organisations can afford to have dedicated project teams. The matrix itself is not the problem, but to work it must be supported by three things:
* an effective corporate project accounting system
* a management system whereby line managers are accountable for the equitable allocation of workload
* a corporate management process that meaningfully links total company labour-hour requirements with recruiting, staffing, and remuneration policies.

It is rare for there to be enforceable internal contracts in organisations for the provision of goods and services between two parties;
Without proper corporate systems for integrating project and business accounting, the line manager has no incentive to overrun departmental budgets for the sake of a project.

Problems with authority
There are two main causes of problems related to the exercise of authority: first, confusion about the nature of authority, which results in confusing seniority with authority and not recognising that seniority, is irrelevant in project management processes; and second, confusion between organisational style and authority structure.

Problems with progress measurement
There are many problems with assessing real progress in projects. At the heart of progress measurement is the establishment and maintenance of two baseline sets: the cost and schedule baseline—our 'S-curve' and the design baselines (scope management). To assess progress, current cost and schedule data are compared to the cost and schedule baselines. There is also the need to assign staff time consistently to project tasks in this accounting system. The nature of technical risk is such that there can be a dramatic change in circumstances. Connected to the previous problem is the fact that progress is measured in dollars, but low-cost items can dramatically affect the schedule.

'Baseline' means a controlled set of agreed documents. The control is that no-one can change them without some approval / review from all the other parties. The agreed is that a baseine is much more than something like a novel - it is not one person's view, but rather an agreement. Finally it is a collection of documents that inter-act - for example a PMP + Scope + Estimate + Schedule + Budget or something. It is almost always a collection of items.

Business environment
Perhaps the largest source of uncertainty is the business environment in which projects have to operate. Most importantly, the instability, from a project management point of view, of the management operating environment which, in turn, is caused by the very competitive and fast-moving business environment.