Topic 2: Definition and authority

Defining boundaries

We need to agree what boundaries there shall be, and who shall speak for us, so that it is clear that agreement has been reached.

When does a project start? If we think about that question for a moment, a number of possible answers come to mind. In fact, all are possible answers (though none is entirely satisfactory). As we understand from our 'continuum' discussion, the question is the wrong one. There is no definitive answer. A more appropriate question is, 'How will we formally define projects in our organisation?'

Process boundaries have two important practical implications for organisations: accountability and funding. The rationale for separating the various processes is to reflect the type of work being done within each process and the way in which that work will be resourced, controlled, and funded. Clear accountability should mean a person is clearly responsible for monitoring and controlling the funding.

* Separate budgeting implies separate accountability.
* Accountability for budget, and performance against budget, implies authority to approve expenditure against budget—that is, approve funding in that activity category.

Funding approval implies control of resources.
* Accountability for performance against budget implies control of output, hence control of output of controlled resources.
* There is a lot of project activity that is outside the control of the project manager
* Without the authority to control funds, there can be limited control of resources, hence limited control of output.

* Boundaries are needed in order define manageable 'chunks' to which accountability for performance can be formally assigned.
* With accountability comes responsibility and authority—authority to 'speak for' a constituency.
* Authority is legitimised through formal organisational processes. With the position of spokesperson for a constituency comes defined responsibility and the necessary authority to discharge that responsibility.
* Legitimate authority is enforceable through power over funding, and the power to dismiss.
* Consequently, formal authority enables control of resources, control of resource output, control of approval to work, ability to dismiss.
* Without the authority to control funds, or to recruit and dismiss labour, little management influence can be exercised.

Defining authority

From our project management perspective, 'authority' means being the legitimate representative of a particular interest group. We will see later that this means having the responsibility for making particular types of decisions.

There are seven key constituencies which affect us directly as project managers.
(i) The customer is an obvious constituency whose primary interest is that of acquiring the most cost-effective solution to an identified need.
(ii) 'Prime contractor' is used here in its broadest sense to indicate the entity that takes full responsibility for the legal, social, commercial and technical delivery requirement agreed with the customer.
(iii) The project constituency is the one whose interest is to see that the project has the required competencies and resources, budget, terms and conditions, specifications, and allowed time to enable the project to discharge its obligations successfully.
(iv) The Control Account Manager; within the project, there are often large WBS items that require a team to complete, and should have a schedule, budget and deliverables in their own right.
(v) The Design Specialist; the primary and key interest of the design specialist group is to ensure that the evolving design will meet the specifications for functionality, performance and quality.
(vi) The sub-project constituency includes subcontractors and other functional or product groups that may be part of the project effort.
(vii) The organisation's functional groups are another constituency with their own interests and authority.

Each of the constituencies will have one person nominated to represent that constituency.
The constituency authorises that person to speak on its behalf. Regardless of the positions or titles, there are various distinct functions that need to be performed for the effective execution of an acquisition contract.

(a) The sponsor is the organisational group that will fund the acquisition of the new capability.
(b) Also within the customer group, the project authority or customer representative is that entity who acts on the sponsor's behalf to ensure the efficient management of the acquisition contract.
(c) The acceptance authority function is usually discharged by the project authority, but not always.
(d) We now move into the next constituency—that which earlier we named 'prime contractor'. The business owner is the 'top' of this constituency.
(e) The project owner fulfils a similar function within the prime contractor constituency to the one the project authority fulfils in the customer constituency. The project owner is the person in the prime contractor's organisation who takes responsibility (and thus is accountable) for ensuring that the business's interests are satisfied in the execution of the project.

The project manager's function is one that can be quite simply stated:
* to agree with the project owner on the cost, schedule, quality and acceptance criteria for the project
* to understand and conform to the criteria by which trade-off decisions and priorities will be made during the course of the project
* to ensure that the project is effectively managed so that the measures of success are satisfied.

The 'design presentation authority' is a function normally 'owned' and performed by the project manager.

The System test authority is a technical function, separate from the design function. Its purpose is to ensure that the system has been tested effectively against the system requirements, not just the detailed design requirements.

The 'system design authority' is the entity that has the responsibility for ensuring that the system design meets the requirements specified in the approved system specification.

The design authority has been delegated to the subsystem supplier by the prime contractor through the act of granting a subcontract.

The important distinction between the system design authority and the design authority is that the system design authority has no authority to alter the design of the subsystem. The system design authority can specify only the functional, performance, quality and interface requirements of the subsystem, not how the design will satisfy those requirements.

Defining agreement

Beneath the complicated surface of any project there are some simple patterns and principles:
* clarity of boundaries
* agreement between parties
* 'flowdown' of agreement.

The fundamental pattern to projects is that they are a layered series of agreements made between constituencies. The agreements are formalised by a public gesture—a 'signing'— as that is the most efficient way of unambiguously communicating to everyone in the wide range of groups that agreement is reached.

The unchanging pattern from our project management perspective is that there is a single agreement made at the 'top', which ripples down and spreads throughout the constituencies until all groups are committed to a defined goal. The single agreement defines:
* what is to be delivered
* what the budget is
* when it is to be delivered
* what the acceptance criteria are.

At each level the agreement is always the same.

The agreement between customer and contractor is formalised in the main 'head' contract. Between the business and the project owner, the agreement may not have a formal name but will be a formal organisation memorandum authorising the expenditure of the required funds and defining the broad scope of the project. The agreement between the project owner and project manager will be an expanded form of the chief executive's document.

Between the project manager and the cost account managers there are at least three documents: (i) the project plan (ii) the project schedule (iii) the cost account budget authorisation forms.

The project plan is owned by the project manager and defines sub-project boundaries, authorities and processes to be followed for the management of the project. Promulgation of the plan sets in train further defining and authorising activity.

Schedules operate in two ways:
* as agreements between two parties of delivery dates
* as dynamic network tools that allow 'what if' scenarios to be modelled when problems need to be worked around, and as dynamic scheduling tools that allow day-to-day planning of work effort.

A master schedule will be derived from the program requirements in the head contract. The master schedule is then broken down to reflect how the project will undertake the work. All key dates and milestones are transposed into this more detailed schedule.

The schedule that emerges is the project schedule or intermediate schedule. The project schedule sets the delivery dates and key milestones for the sub-projects. The schedules that emerge are the detailed schedules.

Behind all agreements is this concept of enforcement—the recognition that, if required, agreements can be upheld through force. With projects, the project manager must formally have the power to terminate the services of those parties that enter into project agreements or to refuse payment for claimed effort.

Common problems

There are four areas where problems commonly arise through confusion over boundaries and authority:

* formal design reviews
* acceptance testing and delivery
* project reviews
* formal progress reviews.

In formal design reviews a wide range of parties is represented: the project authority, the sponsor (or usually a person representing them), the project manager, perhaps the project owner, designers, systems analysts, specialists, subsystem vendors.

At some point someone will express a view that the design is defective in some major or minor way. As
all attendees are technically knowledgeable, the observation is probably correct. The question that arises is who has the problem? It depends first on what was agreed, second on whether the agreement was broken,
and third on whether the technical detail in the agreement was flawed.

Complex systems require extensive acceptance testing by users before final acceptance. Who has the problem will depend on what agreement was broken or what was at fault. The key point here for project managers is that acceptance problems are just as likely to result from communication problems between the user and the project authority on what was contracted to be delivered, as they are from deficiencies in the delivered system.

All parties are able to distinguish between technical authority, management authority and organisational seniority. At the root of problem in Project Reviews is confusion between 'hats' that people wear.

With regards to Schedules, the customer looks at project schedules displayed at review meetings. Mistakenly believing the project schedules to be contractual documents, the customer thinks they must approve any changes. There is nothing complicated here, just confusion over what is part of a formal agreement and what is being provided as supplementary information, but which is owned by only one party.