Establishing Clear Project Management Guidelines

7/30/2019 Establishing Clear Project Management Guidelines

1/4

GULF PROJECT MANAGEMENT MAGAZINE | SEPTEMBER 2007 | WWW.PMI-AGC.COM

Establishing Clear Project

Management Guidelines

When I come into an organisation that hasnever used formal business analysis orproject management processes, one of

my first challenges is to address the uncertaintyand confusion over some key concepts andtools. For example, almost immediately after Istart meeting with decision-makers, I encounterquestions like these:

What is the difference between the business

vision, mission and goals?How does the business requirements document(BRD) differ from the project charter?

Why do we need a project charter?

Why create astatement ofwork (SOW) ifyou already havethe BRD?

Do we reallyneed all of theseprocesses inorder to get aproject going?

Although these questions are rhetorical to aprofessional business analyst or project manager,they betray a fundamental absence of structured,disciplined process management by those who askthem. My task then becomes clear: I must provideeducation on the value of formal processes andprocedures by packaging them into digestibleand relevant concepts, techniques and artefacts.

Toward that end I have developed the following

four tools:Hierarchy of business targets

Statement of work template

Project management guidelines

Glossary of terms

Hierarchy of Business TargetsThe hierarchy of business targets, shown in Figure1 on the next page, serves to orient the decision-maker or team leader in the logical process of howwork should progress from the idea stage to theimplementation stage, with a clear indication at eachstep of what the deliverables are. For example, inthe business domainwhich I refer to as the area

above the yellow linewe deal with the vision (TOBE state) of the business, the mission (AS IS state)and the various specific goals that support the visionand mission.

Below the yellow lineis the project domain,which is where the moreabstract elements ofvision, mission and goalcome down to earth andevolve into concretework tasks. The projectcharter is shown as theauthorizing documentthat specifies both a

project number (presumably assigned by a centralcontrol organization for tracking purposes) andthe funding authorization. It basically sanctionsthe commitment of resources to formally plan andconduct collection of business requirements, whichfirst involves the requirements work plan (RWP) andthen culminates in production of the BRD.

Once the charter, RWP and BRD are complete, theanalysis phase of the project is finished and theorganization has a clear understanding of exactly

why it has approved this project and how the finaldeliverables will benefit the business. This is a criticalstep for managing and controlling subsequent efforts,which are now specified in the statement of work.

by Michael S. Zambruski, PMP

what is the difference between

the business vision, mission

and goals?


2/40 GULF PROJECT MANAGEMENT MAGAZINE | SEPTEMBER 2007 | WWW.PMI-AGC.COM

Statement of WorkThe statement of work is another concept that meansdifferent things to different audiences, so its importantto ensure uniform understanding and application byproviding a template, which contains the sectionsoutlined in the following table of contents:1. Project Description

a. Goalb. Approachc. Tacticsd. Prioritiese. Milestones

f. Out of scope2. Project Teams

a. Leadership teamb. Operations teamc. Backups/alternates

3. Success Criteriaa. Key deliverablesb. Quality metricsc. Traceability matrix

4. Assumptions5. Constraints6. Change Control Process7. Attachments

a. Business Requirements Documentb. Project Budgetc. Project Pland. Risk Management Plane. Risk Logf. Escalation Policyg. Communications Planh. Documentation Protocoli. Test Strategy

j. Training Strategy

One thing that I stress at this stage is the differencebetween structure and rigidity. Structure means usingthe statement of work template as a standard, repeatablemethod of ensuring that nothing is overlooked. For thatreason, an SOW is required for each chartered project.Rigidity, however, means never deviating, and that isnot practical since each project is different. Therefore,

Establishing Clear Project Management Guidelines

Project Statement of Work (SOW)

for achievingBUSINESS GOAL C

NEXT - Project Execution, Control, and Closure

CONTENTSApproach

Tactics

Priorities

Progress Milestones

In vs. Out of Scope

Success Criteria

- deliverables

- traceability matrix

- quality metrics

Assumptions

Constraints

CONTENTSDetailed Project Budget

Project Team Roster

Comprehensive Project Plan

Risk Management Plan

Escalation Policy

Communications Plan

Documentation Protocol

Test Strategy

Training Strategy

Planning Phase of Project = Project Goal = achieve Business Requirements in BRD

= Analysis Phase of the Project

> Business Requirements Work Plan (RWP)

> Business Requirements Dosument (BRD)

Initiation Phase of Project =

> project number

> funding authorization

Project Charterfor achieving

BUSINESS GOAL C

Business Requirementsfor achieving

BUSINESS GOAL C

BUSINESSVISION

The TO BE State of the Enterprise

BUSINESSVISION

The TO BE State of the Enterprise

BUSINESSGOAL E

BUSINESSGOAL A

BUSINESSGOAL B

BUSINESSGOAL C

BUSINESSGOAL D

D

O

M

A

I

N

B

U

S

I

N

E

SS

P

R

O

J

EC

T

D

O

M

A

I

N

Fig. 1 - Hierarchy of Bus iness Targets


3/4

GULF PROJECT MANAGEMENT MAGAZINE | SEPTEMBER 2007 | WWW.PMI-AGC.COM

although the structure of SOWs will be the same,their individual details will reflect specific conditionsand will therefore differ from project to project. Forexample, although every project and associatedSOW will have a formal escalation policy, the policyitself might be one-day escalation for one projectand one-week escalation for another. This situationalflexibility is vital to the effective application of a

standardized tool such as the SOW.

Project Management Guidelines

These guidelines describe policies, procedures,techniques, and artefacts for uniform management ofprojects throughout the organization. By combiningstandardization with responsive flexibility and bestpractices, these measures are designed to achieveon-budget, on-schedule performance while carefullymanaging scope, quality and risk for all projects.

Project AuthorizationProjects are authorized for the purpose of producingdeliverables that are specified in a formal BusinessRequirements Document (BRD), which supports theoverall vision, mission and goal(s) of the sponsoringorganization.

Project InitiationOnce the BRD, funding approval and a designatedsponsor are confirmed, the project is formally initiatedthrough the documents referenced below.

Statement of Work (SOW)This specifies the project goal, the overall approachand tactics for achieving the goal, a high-leveltimeframe with key milestones, funding authorizationand details, success criteria, assumptions,constraints and traceability to documented businessrequirements. Essential to the SOW is a clearstatement of all work that is in scope as well as outof scope.

List of PrioritiesThis is a hierarchical list of key objectives or initiativesthat support the project goal and form the basis of a

comprehensive project plan. These can be recordedin a stand-alone document or as part of the SOW.

Project Team RosterAs early as possible a list of core team members,including any vendor staff, should be compiled.Contact information, area(s) of specialty andresponsibility and alternate representatives shouldbe indicated for each person. This can be recordedin a standalone document or as part of the SOW.

Project PlanThis document serves as the main control mechanismboth by specifying project phases and by decomposingthese phases into specific tasks with associatedtimeframes, resources, dependencies and deliverables.During project implementation, it also serves as a statustool by showing completion progress. It is typicallyincluded as Attachment C to the SOW and can be donein MicrosoftProject or Excel, or Adobepdf format.

Project ImplementationAs soon as formal project analysis begins, the protocolsbelow must be defined and regularly followed.

Risk ManagementIdentifying, analysing, recording and managing risk is acollaborative effort of the project team and sponsor. Itshould be done as soon as the project is approved, butno later than commencement of project implementation.It is typically included as Attachment D to the SOW.

EscalationEspecially with complex projects, a formal escalationpolicy is needed to ensure timely resolution of tasks,issues and decisions, which involve negotiableor debatable viewpoints. It is typically included asAttachment F to the SOW.

CommunicationThis includes the format, media (including electronic),and points of control for information disseminated toteam members and stakeholders. Key elements ofsuccessful communication include consistent delivery,

comprehensive horizontal and vertical distribution, andtimeliness. The communication protocol also addressesproject status meetingsincluding their frequency,duration, location, attendees and standing agenda.One of the first meetings should be the project kick-off, where the stakeholders and key members of theproject team participate in a detailed discussion of theSOW. The Communications Plan is typically included asAttachment G to the SOW.

DocumentationThe mode, repository and version control of project

documents must be formally defined and continuouslymaintained. Documented project requirements, scope,work plans, policies (including escalation and riskmanagement), team composition and vendor contractsmust be easily retrievable and always up-to-date.

The Documentation Protocol is typically included asAttachment H to the SOW.



4/4 GULF PROJECT MANAGEMENT MAGAZINE | SEPTEMBER 2007 | WWW.PMI-AGC.COM

TestingComprehensive validation testing must be planned andconducted against the quality metrics specified in theSOW so that it is absolutely clear when deliverablesmeet business requirements. Interim verification testsshould be developed and conducted at appropriateintervals to gauge progress and mitigate risk. The

Testing Protocol is typically included as Attachment Ito the SOW.

TrainingDevelopment and delivery of educational material mustbe assessed at each project phase to determine theneed for and type of appropriate training.

GlossaryThis glossary can serve as a way for your organizationto get on the same page--language-wise and business-wise.

The business goal is a major milestone supportingthe vision and/or mission.

The business mission outlines the AS IS direction ofthe organization.

The business requirements detail the components ofthe business goal.

RWP =The requirements work plan outlines theeffort needed to collect, document, analyse andvalidate business requirementsBRD = The business requirements documentrecords the formally approved businessrequirements, which become the deliverables of

the project

The business vision defines the strategic TO BE stateof the organization.

The project charter sanctions official pursuit of thebusiness goal(s), as stipulated in the BRD.

The project goal is to achieve the businessrequirements.

The project statement of work (SOW) is the script forachieving the project goal.

A lack of general project knowledge within anorganization can be almost as dangerous as a lack of

project management. The hierarchy of business targets,statement of work template, project managementguidelines and glossary of terms should help yourorganization combat this issue and help you and yourorganization get on track to more successful projects.

Authors Biography:

Michael S. Zambruski, PMP,is PMO Director for UMass

Memorial Medical Center

in Worcester, MA, UnitedStates, and has an MBA from

Southern Illinois University

and a BA/BS from Georgetown

University. His background

includes telecommunications,

information technology, health

care, environmental services,

real estate, aerospace, and

the federal government. He is

an adjunct assistant professor

at Quinnipiac University

and a senior instructor in

project management with ESI

International. His book, TheBusiness Analyzer & Planner,

has been published through

the American Management

Association. You can contact

Mike at michael.zambruski@

snet.net.


Documents

Establishing Clear Project Management Guidelines