it project management on track

CONTENTS AT A GLANCE

1 Initiating the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Working with Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4 Managing the Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5 Creating the Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

6 Building the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

7 Organizing a Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

8 Managing Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

9 Implementing the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

10 Revising the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

11 Enforcing Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

12 Completing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

A IT Project+ Exam Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

B Working as an Independent Contractor . . . . . . . . . . . . . . . . . . . . . . . . . 535

C Critical Exam Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

D About the CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

vii

ProjMan /IT Project Management: On Track from Start to Finish, 3rd ed. / Phillips / 015-3/ Front Matter

P:\010Comp\ProjMan\015-3\FM.vpWednesday, January 27, 2010 1:52:01 PM

Color profile: DisabledComposite Default screen

CONTENTS

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiiIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

1 Initiating the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Defining the Project Management Life Cycle . . . . . . . . . . . . . . . . . . . . 2

Initiating the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Executing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Monitoring and Controlling the Project . . . . . . . . . . . . . . . . . . 6Closing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Gathering Project Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Establishing the Project Requirements . . . . . . . . . . . . . . . . . . . 8Possessing Multiple Personas . . . . . . . . . . . . . . . . . . . . . . . . . . 14No Other Choices? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Interviewing Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Interviewing the Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Identifying the Project Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Creating Reasonable Expectations . . . . . . . . . . . . . . . . . . . . . . 24Creating the Project Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Project Charter Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Finding the Completion Date . . . . . . . . . . . . . . . . . . . . . . . . . 29Initiating Processes and the CompTIA Project+ Exam . . . . . . . 31

Q&A Chapter Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Chapter Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Quiz Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Exercise Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

ix




2 Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49How to Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Defining the Business Need . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Creating a Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Creating the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Writing the Project Scope Statement . . . . . . . . . . . . . . . . . . . . 65

Establishing Project Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Obtaining Budget Dollars . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Creating an Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Create a Milestone List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Manage the Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Contingency Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Planning Processes and the CompTIA Project+ Exam . . . . . . . 82


3 Working with Management . . . . . . . . . . . . . . . . . . . . . . 99Defining the Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Working in a Functional Organization . . . . . . . . . . . . . . . . . . . 100Working in a Matrix Organization . . . . . . . . . . . . . . . . . . . . . . 101Working in a Projectized Organization . . . . . . . . . . . . . . . . . . . 102

Presenting the Project to Management . . . . . . . . . . . . . . . . . . . . . . . . . 103Start at the End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103The WIIFM Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Tailor the Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Role of a Salesperson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Defining Managements Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108How Projects Get Initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Management Theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Delegate Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Focusing on the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Inventing a Project Kickoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Set the Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120How Management Fits In . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Defining the Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

x IT Project Management: On Track from Start to Finish




Creating Management Alliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Working Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Following Organizational Governance . . . . . . . . . . . . . . . . . . . 124Dealing with Challenging Bosses . . . . . . . . . . . . . . . . . . . . . . . 126Working with Good Bosses . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Management and the CompTIA Project+ Exam . . . . . . . . . . . . 128


4 Managing the Project Scope . . . . . . . . . . . . . . . . . . . . . . 151Creating the Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Gathering Requirements Through Communications . . . . . . . . 153Writing the Project Scope Statement . . . . . . . . . . . . . . . . . . . . 155

Defining the Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . 157Working with a WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Coordinating WBS Components . . . . . . . . . . . . . . . . . . . . . . . 159Defining a WBS Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161The Mechanics of Creating a WBS . . . . . . . . . . . . . . . . . . . . . . 162Why You Need a WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Creating a WBS Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Obtaining Stakeholder Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Presenting to the Project Sponsor . . . . . . . . . . . . . . . . . . . . . . . 166Presenting to Key Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 166Scope Management and the CompTIA Project+ Exam . . . . . . . 168


5 Creating the Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Budget Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Determine the Estimate Type . . . . . . . . . . . . . . . . . . . . . . . . . . 193Implementing Bottom-Up Cost Estimates . . . . . . . . . . . . . . . . . . . . . . . 194

Allowance for Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Creating a PERT Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Contents xi




Using Top-Down Estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Using Analogous Estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Using Parametric Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Budget at Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Zero-Based Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Determining Project Expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

The Cost of Goods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Estimating Work Hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Tracking Budgetary Expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Runaway Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Keeping Track of Expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Project Budgets and the CompTIA Project+ Exam . . . . . . . . . . 218


6 Building the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . 235Building the Project Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Project Plan Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Creating the Project Scope Management Plan . . . . . . . . . . . . . 240Defining the Project Schedule Management Plan . . . . . . . . . . . 243Building the Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . 252Analyzing the Project Network Diagram . . . . . . . . . . . . . . . . . 254Creating the Project Cost Management Plan . . . . . . . . . . . . . . 258Planning for Project Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Preparing for Managing a Project Team . . . . . . . . . . . . . . . . . . 262Writing the Project Communications Management Plan . . . . . 264Planning for Project Risk Management . . . . . . . . . . . . . . . . . . 265Building the Project Procurement Management Plan . . . . . . . . 271Planning and the CompTIA Project+ Exam . . . . . . . . . . . . . . . 277


xii IT Project Management: On Track from Start to Finish




7 Organizing a Project Team . . . . . . . . . . . . . . . . . . . . . . . 295Assessing Internal Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Identifying Resource Requirements . . . . . . . . . . . . . . . . . . . . . 297Experience Is the Best Barometer . . . . . . . . . . . . . . . . . . . . . . . 297Rsums and Skill Assessments . . . . . . . . . . . . . . . . . . . . . . . . . 298Create a Roles and Responsibilities Matrix . . . . . . . . . . . . . . . . 299Learning Is Hard Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Creating a Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Defining Project Manager Power . . . . . . . . . . . . . . . . . . . . . . . 301Hello! My Name Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Where Do You Live? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Building Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Interviewing Potential Team Members . . . . . . . . . . . . . . . . . . . . . . . . . 306Why You Need Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306How to Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Managing Team Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Dealing with Team Disagreements . . . . . . . . . . . . . . . . . . . . . . 310Phases of Team Development . . . . . . . . . . . . . . . . . . . . . . . . . . 311Project Management Is Not a Democracy . . . . . . . . . . . . . . . . 312Dealing with Personalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314Use Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Disciplining Team Members . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Using External Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Finding an Excellent IT Vendor . . . . . . . . . . . . . . . . . . . . . . . . 318Interviewing the Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Organizing a Project Team and the CompTIA

Project+ Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322Q&A Chapter Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Chapter Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Quiz Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Exercise Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

8 Managing Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Leading the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Establishing the Project Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Contents xiii




Mechanics of Leading a Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Working with Team Members . . . . . . . . . . . . . . . . . . . . . . . . . 342

Team Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Meeting Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Meeting Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Using a Meeting Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . 345Meeting Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

Maintaining Team Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Background and Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Working Toward the Finish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Commitment from the Project Teams Managers . . . . . . . . . . . 349Project Completion and Team Members Growth . . . . . . . . . . 350

Motivating the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Understanding Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351What Team Members Need . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Theorizing on Management and Leadership . . . . . . . . . . . . . . . 355Managing a Project Team and the CompTIA Project+ Exam . . . . 356


9 Implementing the Project Plan . . . . . . . . . . . . . . . . . . . . 375Reviewing Assignments with the Project Team . . . . . . . . . . . . . . . . . . . 376Focus on the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Hosting a Project Status Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Tracking Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Creating a Reporting Process . . . . . . . . . . . . . . . . . . . . . . . . . . 381Status Collecting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Tracking Financial Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Tracking Actual Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387Determining Earned Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Controlling Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389Calculating the Cost Performance Index . . . . . . . . . . . . . . . . . . 391Calculating the Scheduled Performance Index . . . . . . . . . . . . . 392

xiv IT Project Management: On Track from Start to Finish




Predicting Project Performance . . . . . . . . . . . . . . . . . . . . . . . . 393Calculating the To-Complete Performance Index . . . . . . . . . . . 393Executing the Project and the CompTIA Project+ Exam . . . . . 395


10 Revising the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . 411Defining the Need for Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412Establishing Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Impacts of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414Project Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Change Impact Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Internal Project Trouble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Implementing Project Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422Changes from Internal Forces . . . . . . . . . . . . . . . . . . . . . . . . . . 423Changes from External Forces . . . . . . . . . . . . . . . . . . . . . . . . . 424Negotiate for Tiered Structures . . . . . . . . . . . . . . . . . . . . . . . . 425Extension of Time for Delivery . . . . . . . . . . . . . . . . . . . . . . . . 425

Issue Management Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426Delaying a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Coping with Vendor Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . 428Rebuilding Management Support . . . . . . . . . . . . . . . . . . . . . . . 428Focus and Refocus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430Renewal of Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430Revising the Project and the CompTIA Project+ Exam . . . . . . 431


Contents xv




11 Enforcing Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449Defining Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450Quality of the Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Producing a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451Producing Goods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454Quality vs. Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Quality of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456Managing the Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Project Information Center . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Web Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Software Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Quality Management as a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Quality Phases of Project Management . . . . . . . . . . . . . . . . . . . 461

Ensuring Quality Throughout the Project . . . . . . . . . . . . . . . . . . . . . . . 462Planning for Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463Traditional Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 465Traditional Quality Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 466Implementing Quality Control . . . . . . . . . . . . . . . . . . . . . . . . . 467Analyzing Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469Total Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Creating a Strategy for Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472Revisiting the Iron Triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . 472Progress Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Quality and the CompTIA Project+ Exam . . . . . . . . . . . . . . . . 475


12 Completing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . 489Completing the Final Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Going the Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491Examine the Critical Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49398 Percent Done Is Not Complete . . . . . . . . . . . . . . . . . . . . . . 494

xvi IT Project Management: On Track from Start to Finish




The Project Postmortem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495Reviewing for Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495Assessing the Project Deliverables . . . . . . . . . . . . . . . . . . . . . . . 495Examining the Projects Worth . . . . . . . . . . . . . . . . . . . . . . . . . 496Third-Party Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Obtaining Final Sign-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498Using a Project Transition Plan . . . . . . . . . . . . . . . . . . . . . . . . 499Obtaining Client Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

Post-Project Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Creating the Final Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Evaluating Team Members Performance . . . . . . . . . . . . . . . . . 503Declaring Victory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504Declaring Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504Cheers! Celebrating Victory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

Project Closure and the CompTIA Project+ Exam . . . . . . . . . . 506Q&A Chapter Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

Chapter Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516Quiz Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518Exercise Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

A IT Project+ Exam Objectives . . . . . . . . . . . . . . . . . . . . . 521Response Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5221.0 Preproject Setup/Initiating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

1.1 Explain the Requirements to Completea Preproject Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

1.2 Identify the Characteristics of a Project . . . . . . . . . . . . . . . . 5231.3 Summarize the Steps Required to Validate a Project . . . . . . 5231.4 Explain the Components of a Project Charter . . . . . . . . . . 5241.5 Outline the Process Groups of the Project Life Cycle . . . . . 5241.6 Explain the Different Types of Organizational Structures . . . . 524

2.0 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5252.1 Prepare a Project Scope Document Based

on an Approved Project Charter . . . . . . . . . . . . . . . . . . . . . . 5252.2 Use a Work Breakdown Structure (WBS) and WBS

Dictionary to Organize Project Planning . . . . . . . . . . . . . . . 5252.3 Outline a Process for Managing Changes to the Project . . . 525

Contents xvii




2.4 Develop a Project Schedule Based on WBS, Project Scope,and Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 526

2.5 Given a Desired Deliverable, Apply the Appropriate Tooland/or Method to Produce the Appropriate Outcome . . . . . 526

2.6 Given a Scenario, Interpret the Results of Usingthe Following Tools and/or Methods . . . . . . . . . . . . . . . . . . 526

2.7 Identify Components of an Internal/ExternalCommunication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

2.8 Outline the Components of a Risk Management Plan . . . . 5272.9 Identify Roles and Resource Requirements Based

on WBS and Resource Availability . . . . . . . . . . . . . . . . . . . . 5272.10 Identify Components of a Quality Management Plan . . . . 5272.11 Identify Components of a Cost Management Plan . . . . . . 5272.12 Explain the Procurement Process in a Given Situation . . . 5282.13 Explain the Purpose and Common Components

of a Transition Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5283.0 Project Execution and Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

3.1 Coordinate Human Resources to Maximize Performance . . . . 5283.2 Explain the Importance of a Project Kick-Off Meeting

and Outline the Common Activities PerformedDuring This Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

3.3 Recognize the Purpose and Influence of OrganizationalGovernance on a Projects Execution . . . . . . . . . . . . . . . . . . 529

3.4 Given a Scenario, Select Which Component(s) of a ProjectPlan Is Affected and Select What Action(s) Should Be Taken . . . 529

4.0 Change, Control, and Communication . . . . . . . . . . . . . . . . . . . . . . 5304.1 Given a Scenario, Implement Proper Change

Management Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 5304.2 Evaluate the Impact of Potential Changes

to the Triple Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5314.3 Using the Risk Management Plan, Determine an Appropriate

Response to Potential Risk / Opportunity Events . . . . . . . . . 5314.4 Given a Scenario, Execute Appropriate

Resource Leveling Techniques . . . . . . . . . . . . . . . . . . . . . . . 5314.5 Explain the Appropriate Steps to Ensure

Quality of Project Deliverables . . . . . . . . . . . . . . . . . . . . . . . 532

xviii IT Project Management: On Track from Start to Finish




4.6 Identify Potential Tools to Use When a Project DeliverableIs Out of Specification as Defined in the Quality Baseline . . . . 532

4.7 Given a Scenario, Calculate and Interpret the Resultsof Earned Value Measurement (EVM) . . . . . . . . . . . . . . . . . 532

4.8 Given a Scenario, Manage and Implement InformationDistribution Based on Communications Plan . . . . . . . . . . . 533

4.9 Recognize the Special Communication Needs of Remoteand/or Indirect Project Team Members . . . . . . . . . . . . . . . . 533

5.0 Project Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5335.1 Explain the Importance and Benefits

of Formal Project Closure . . . . . . . . . . . . . . . . . . . . . . . . . . 5335.2 Identify Circumstances in Which Project/Phase Closure Might

Occur and Identify Steps to Take When Closure Occurs . . . 5345.3 Identify the Components and Purpose

of Closing Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 534

B Working as an Independent Contractor . . . . . . . . . . . . 535Getting (and Keeping) the Deal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536Making Yourself at Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536Becoming a Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Delivering More Than What You Promise . . . . . . . . . . . . . . . . . . . . . . 538

C Critical Exam Information . . . . . . . . . . . . . . . . . . . . . . . 539Test-Passing Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Days Before the Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Practice the Testing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Testing Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541Answer Every QuestionOnce . . . . . . . . . . . . . . . . . . . . . . . . 542Use the Process of Elimination . . . . . . . . . . . . . . . . . . . . . . . . . 542

Everything You Must Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543The 42 Project Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . 543

Initiating the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543Executing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544Monitoring and Controlling the Project . . . . . . . . . . . . . . . . . . 544

Contents xix




Closing the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545EVM Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545Quick Exam Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546

A Letter to You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

D About the CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Installing and Running MasterExam . . . . . . . . . . . . . . . . . . . . . . . . . . . 556MasterExam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Electronic Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557Removing Installation(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

LearnKey Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . 557

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

xx IT Project Management: On Track from Start to Finish




Chapter 1Initiating the Project

CHAPTER OBJECTIVES

Defining the Project Management Life Cycle

Gathering Project Information

Defining the Project Requirements

Establishing the Completion Date

Creating the Project Charter

From the Field: Interview with Carl Danneels

Q&A Chapter Quiz

Chapter Exercises

ProjMan /IT Project Management: On Track from Start to Finish, 3rd ed. / Phillips / 015-3/ Chapter 1Blind Folio 1:1

ProjMan /IT Project Management: On Track from Start to Finish, 3rd ed. / Phillips / 015-3/ Chapter 1Blind Folio 1:1

P:\010Comp\ProjMan\015-3\ch01.vpTuesday, January 19, 2010 2:28:14 PM


Welcome to information technology (IT) project management. IT projectmanagement is different from managing any other project you may have workedon in the past. In the world of information technology, weve got attacks on allfronts: ever-changing business needs, hardware compatibility, software glitches, security holes,and network bandwidth, not to mention careers, attitudes, and office politics.

Dont be scared off! This is also the most challenging and exciting place to be ina company. What you do here will affect the entire organization, will have an impacton profits, and can boost your career, confidence, and life to the next level.

IT project management can be as exciting as a white-water rafting excursion oras painful as a root canal; the decision is yours. What makes the difference betweenexcitement and a sore jaw? Many things: leadership, know-how, motivation, and,among other things, a clear vision of what each project will produce, what it will cost,and when it will end.

This first chapter will help you build a strong foundation for managing successfulIT projects. Like anything else in the world, project management requires adequateplanning, determination, and vision for success. Ready to start this journey? Lets go!

Defining the Project Management Life CycleBefore you hop into the launch of a project, its paramount that you understand thelife cycle of project management. A life cycle is just a pleasant way of saying thingsare created, they have a life, and then they go away. Projects are temporary; they donot, thankfully, last forever. Operations, however, describe the ongoing core businessof an organization. Operations are the day-to-day tasks, business focus, and purpose ofan organization; theyre what companies do. Projects are unique endeavors that dontfit into the day-to-day model and activities of an organization. Projects are specialundertakings to create unique products, services, and conditions.

A project, technically, is a temporary endeavor to create a unique product orservice. Projects are an undertaking outside of the normal operations of an entity.For example, you might roll out a new application, install new monitors, create anew portion of a web site, or establish a new call center for application support. Insome organizations, such as ones composed of application developers or consultants,or IT integration companies, everything they do is a project because they completeprojects for other organizations. Consider a company that creates custom

ProjMan /IT Project Management: On Track from Start to Finish, 3rd ed. / Phillips / 015-3/ Chapter 1

2 IT Project Management: On Track from Start to Finish


P:\010Comp\ProjMan\015-3\ch01.vpMonday, December 21, 2009 4:17:58 PM


applications for other organizations. Their operation is an ongoing series of projects.The organization that completes the project work is called the performingorganization.

Its not that unusual in the IT world to meet companies that perform projects forother organizations. Your company might even be one of those entities, or you mightpurchase goods and services from a company that completes projects for you. Anorganization whose main income is generated by completing projects for othersmight be referenced as a company that does management by projects. Even thesecompanies, however, still have a distinction between operations and projects.

All projects move through a logical progression of activities to reach the projectclosing. You could examine a project in construction, health care, manufacturing,or technology, and youd see the same set of project management processes thatmove the project forward. The framework that all projects share is called theproject management life cycleits universal to all projects in the world. The projectmanagement life cycle describes the evolution of project process groups that will movea project from initiation to project closure. Figure 1-1 captures the project managementlife cycle and shows how all projects use different process groups to move the projecttoward its closing.


Chapter 1: Initiating the Project 3


FIGURE 1-1

The projectmanagement lifecycle usesprocess groupsto move theproject forward.



You might hear the terms project life cycle and project management life cycle usedinterchangeably. Technically, these are not the same thing. The project managementlife cycle is universal to all projects and consists of the five process groups: initiating,planning, executing, monitoring and controlling, and closing. A project life cycledescribes the unique phases of a project thats specific to the discipline and natureof the project. For example, you would not have the same phases in a constructionproject that youll experience in a software development project. The phases of theproject compose the projects life cycle, whereas all projects use the project managementlife cycle thats composed of the process groups.

Initiating the ProjectProject initiation is the official launch of the project, and its the real focus of thischapter. Initiation is based on identified business needs that justify the expense, risk,and allotment of resources for the project to exist. Its important for IT projectmanagers to keep the idea of the business need in mind throughout the project.Companies dont launch projects because of cool technology, fast gadgets andgizmos, or to be on the bleeding edge of technologythere must be a financialreason behind the project initiation. The business need is linked to the organizationsstrategies and tactics; goals and mission; and responsibility to their shareholders,owners, and customers.

Ill dive into project initiation more in this chapter, but for now know that thisprocess group is responsible for creating the project charter and identifying theprojects takeholders. The project charter is the official document that authorizesthe project manager and the project to exist within the organization. The projectstakeholders are all the people and organizations that are affected by the existenceof the project and the projects outcome. If youre the project manager, youre astakeholder. More on this in just a bitI promise.

Planning the ProjectGood projects need good plans. You, the project team, and many of your stakeholderswill need to know where your project is going and how you plan on getting there.Planning is an iterative project process group that communicates the intent ofthe project manager. It shows which processes will be used in the project, how theproject work will be executed, how youll control the project work, and finally,






how youll close down phases and the project at its end. Planning requires time,resources, and often a budget for testing, experimenting, and learning.

The primary result of the planning process group is the project management plan.This document is actually a collection of smaller plans that address different areas ofthe project. In Chapter 2, Ill go into the details of each one of these project plans,but for now heres a quick overview of what the planning processes help the projectmanager create:

Scope management plan

Scope baseline

Change management plan

Configuration management plan

Requirements management plan

Cost management plan

Cost performance baseline

Schedule management plan

Schedule baseline

Quality management plan

Process improvement plan

Human resources plan

Communications management plan

Risk management plan

Procurement management plan

There are also some project documents, forms, and checklists that can go into thisplan too, but these are the headlines. Many of these plans dont have to be createdfrom scratch each timethatd be a pain. You can adapt previous, similar projectplans as templates for your current projects to save time and effort, and to use thebenefit of historical information during planning. Planning, I want to stress, is aniterative activity. Youll come back to planning over and over throughout the project;planning is not a one-time activity.






Executing the ProjectHeres the meaty stuff of the project: getting the work done. Presented with yourapproved project, your project team goes about the business of getting the projectwork done and creating key results. Project execution is unique to each discipline andis led and directed by the project manager. This is also the area of the project wheremembers of your project team will spend the bulk of their time and effort and wherethe project will spend the bulk of your budget. Its the heart of the projects mission:to create the product or service the stakeholders are expecting.

Project execution includes the quality assurance process, as the project team mustcreate the project work correctly, ideally the first time. Its almost always more costeffective to do the work right the first time than to pay for it to be fixed later. In IT,simple mistakes can mushroom in costly wastes in time and materials. Ill talk allabout quality and the IT projects in Chapter 11. I bet you cant wait.

It is also in the project execution process group that youll acquire, develop, andmanage the project team. Its a fine line between managing your project team andleading the project team. Management is really all about key results; you want yourproject team to get their work done as planned, on time, and according to budget.You want your team to be as committed to the project work as you are. Goodproject management balances management with leadership. Leadership is aboutaligning, motivating, and directing your project team.

The final process in execution is linked to the costs of your project: procurement.Youll need to understand the procurement process, how contracts work, and therules and policies your company has surrounding the procurement process. Most ITprojects need to purchase resources, that is, materials such as software and hardware,in order to satisfy the requirements of the stakeholders. Conducting the procurementsaccording to the procurement management plan can be a time-consuming process,and when times of the essence, that can cost your project.

Monitoring and Controlling the ProjectIn tandem with project execution, you have the monitoring and controlling processgroup. This set of processes ensures that the project work your team is doing is beingcompleted accurately and according to plan. If there are problems, issues, or risks,then the project shifts back to project planning to figure the stuff out before movingback into execution. Monitoring and controlling the project is based on your projectplans, the work of the project team, and shifting conditions within the project.






Youll manage scope, time, and cost changes with the monitoring and controllingprocesses. Its also in this process group that youll work with the project stakeholdersto verify that the project scope has met their requirements so that theyll accept theproject deliverables the project team has created for them. Scope verification is aninspection-driven process that leads to acceptance decisions for the project.

Another inspection-driven process thats done without the stakeholders is qualitycontrol. Quality control is you and the project team inspecting the project work toconfirm that its done correctly before the stakeholders look at what youve created.Quality control is all about you keeping mistakes out of the customers hands. Thisis actually a great example of how project execution and monitoring and controllingwork together. Recall that quality assurance is about doing the project work correctlythe first time. Quality control is about proving that the work was done correctlyandif it is not, then the team does corrective actions to fix the errors.

Monitoring and controlling also provides communication for reporting the overallperformance of the project, the performance of key project deliverables, andinformation on project specifics, such as the time, cost, and risk portions of theproject. Monitoring and controlling also requires that the project manager overseesand administers the procurement agreements with the project vendors.

Closing the ProjectIll address the project closure in detail in Chapter 12, but its important to addressproject closing at the beginning of the project. Because projects are temporary, theproject manager, project team, and other key stakeholders all need to be in agreementas to where the project is going. Youll need to define indicators that signal the projectis complete. Because technology can change so quickly and frequently, it is vital todefine what constitutes the project closure. You dont want a project that drones onand on because of loosely defined requirements.

The closing process group allows project phases and the project as a whole to beclosed. Some documentation, final reports, and communications happen in the finalactivities of the project. All of the project information should be archived for futureusagesometimes called organizational process assets. Basically, the work youve donein your project can be used for supporting the solution youve created, or other projectmanagers can use your project files to help their projects.

The closing process group also includes the close procurement process. Contractswill define how the relationship between the buyer and the seller should end. Thisincludes post-delivery support, warranties, inspections, and payments. When it







comes to closing out the procurement, your company may require a procurementaudit to determine how and where the project monies were spent, what waspurchased, and that all the invoices and contracts are complete.

Gathering Project InformationEverybody talks about project management, but what is it exactly? In someorganizations, any task or duty is considered a project that requires someone tomanage it. Puh-leeze! Project management is the ability to administer a series ofchronological tasks resulting in a desired goal. Some tasks cant be completed untilothers are finished, while other tasks can be done in parallel. Some tasks requirethe skill of a single individual; other jobs in the project require that everyone chipin and lighten the load.

IT project management is the ability to balance the love and implementation oftechnology while leading and inspiring your team members. Of course, the goal ofproject management is not technology for technologys sake, but rather a movementtoward things like improved customer service, enhanced product quality, and increasedprofitability. Add to that mix external factors such as market conditions, competition,demands for new technology, and even the changing pace of technologyits nowonder IT projects can become so frustrating. As you can see in Figure 1-2, projectmanagement is a high-wire balancing act.

The business need of why a project has been created really drives the implementationof a project. Business needs can be to increase efficiency, to increase productivity, torespond to a customer request or a new regulation, or for countless other reasons aproject is initiated. The project manager must understand whats driving the projectand how the project supports the business need, the mission of the organization, andhow the deliverable of the project will be used by the stakeholders.

Establishing the Project RequirementsBefore the actual project work can begin, the project manager must establish theproject requirements with the project stakeholders. Stakeholders are any individuals,groups, or communities that have a vested interest in the outcome of the project.On some projects, the stakeholders may be just one department. On others, whenprojects may affect every department, the stakeholders may be throughout the




P:\010Comp\ProjMan\015-3\ch01.vpTuesday, January 19, 2010 2:27:54 PM



entire organization. Identifying stakeholders is important because their input to theproject requirements early in the project initiation can ensure the projects success.

Of course, on most projects there will be key stakeholders who influence the projectsoutcome: department managers, customers, directors, end users, and other folkswho have direct power over the project work or results. With the input of these keystakeholders, specifically their requirements for the project, constraints on the project,and time and cost objectives for the project, the project manager will be able togather the project requirements to begin building a project plan to create the projectdeliverables. Stakeholders include

Customers and users These are often called the end users, clients, or recipientsof the project deliverables. These stakeholders could be internal to yourorganization or quite literally customers that purchase the deliverable yourproject creates.

Project sponsor This is a person in the organization that has the authorityto grant the project manager power over the project resources, assign a projectbudget, and support the existence of the project. This person also signs theproject charter to officially launch the project and assigns the project managerto the project.



FIGURE 1-2

A projectmanager mustbalancestakeholders,technology, andthe project.



Portfolio review board This group of stakeholders is responsible fordetermining which projects are worthy of the companys capital. They definethe governance of projects and programs within an organization and overseethe selection of the projects, while considering a number of factors such asreturn on investment, project value, risk to reward of proposed projects,and predicted financial outcomes of launching a new project.

Program managers A program is a collection of projects working togetherto realize benefits that the company could not realize if the projects weremanaged independently of one another. The program manager oversees allof these orchestrated projects in her program. If your project is operating withina program, then the program manager is a stakeholder.

Project management office Some organizations use a project managementoffice (sometimes called the PMO) to centralize and coordinate themanagement of projects within an organization, line of business, ordepartment. PMO functions can vary by organization, though most offerproject management support, guidance, and direction for projects withintheir business domain. Its not unusual for a PMO to direct the actual projectmanagement of a project.

Project team These are the people that work on planning and executing theproject plan. Depending on the organization, the project team may workfull-time or part-time on the project, and they can come and go as the projectwork warrants or stick around for the duration of the project.

Functional management Functional management consists of managers ofthe administrative functions of a company; consider finance, human resources,and accounting. Functional management has their own staff and their ownday-to-day duties to keep the operations stable.

Operations management These are managers of the core business area suchas design, manufacturing, and product development. Operations managersoversee and direct the salable goods and services of the organization.

Business partners These are the sellers, vendors, and contractors that maybe involved in a project through a contractual relationship. Business partnerscan provide goods and services such as hardware, software, and subject matterexperts like developers, technical writers, and software testers that you mightneed on your project.






Project manager You are a stakeholder for your project. Youre responsiblefor developing the project plans, keeping the project on track, monitoringand controlling the project, and communicating the project status andperformance. As it goes in project management, if the project succeeds, itsbecause of everyones efforts. If the project fails, then blame the projectmanager.

Clarity is paramount. When the decision has been handed down that your companywill be implementing some new technology, and youll be leading the way, you needa clear, thorough understanding of the projects purpose. Ambiguous projects area waste of time, talent, and money. Before the project begins, you need to know whatexact results signal the projects end. A project truly begins when you know exactlywhat the project will produce.

Once the project is defined, you need clearly stated objectives, requirements, andboundaries for the project. While management may have an ideal timeline for projectcompletion, itll take some planning and research to determine the exact duration ofthe project. The role of a project manager is not permanent but temporary. You, theproject manager, are responsible for setting the goal, developing the steps to get there,and then leading the way for your team to follow.

How will you know what the end result of the project is to be? Ask! Who do you ask?People like the project sponsor can answer these kinds of questions. More about thatlater! You must have a clear vision of the end result, or the project will drone on and onforever and youll never finish. Too often IT projects can roll into project after projectstemming from an original, indecisive, half-baked wish list. Whether you are a full-timeemployee within an organization or a contract-based project manager, you must havea clear understanding of what the end results of the project will be.

Imagine your favorite archeologist maneuvering through a labyrinth of pitfalls,poison darts, and teetering bridges to retrieve a golden statue. In the movies, theresalways some fool who charges past the hero straight for the booty and gets promptlybeheaded. Dont be that guy. Before you can rush off toward the goal of any givenproject, youve got to create a clear, concise path to get there.

To create this path, youll have to interview the decision makers, the users thechange will affect, and any principals involved in the development of the technology.These are the stakeholdersthe people who will use the project deliverables on adaily basis or will manage the people who will use the project deliverables. You musthave a clear vision of what the project takes to create it or youre doomed. Oftenprojects start from a wish list and evolve into a catalog of complaints about the







current technology. One of your jobs in the early stages of the project will be to discernvalid input from useless gripes.

As you begin your project, consider the following questions.

Does the Project Have an Exact Result?Projects that are as indecisive as a six-year-old at an ice cream stand rarely aresuccessful. As a project manager, you must ensure the project has a definable,obtainable end result. At the creation of the project, every project manager, projectsponsor (the initiator of the project), and team member should know and recognizethe end result of the project. Beware of projects that begin without a clearly definedobjective.

While you should be looking for exact requirements that a project is to include,you must also look for requirements that are excluded from a project (for example, aproject that requires all mail servers to be upgraded in the operating system, but notthe physical hardware). As the project takes form, the requirements to be excludedwill become obvious given management, the time allotted for the projectscompletion, and the given budget.

Are There Industry or Government Sanctions to Consider?Within your industry there may be governmental or self-regulating sanctions youwill have to take into account for your project. For example, a banking environmentwill involve regulations dealing with the security of the technology, the backupand recovery procedures, and the fault tolerance for the hardware implemented.Government regulations vary by industry, and if your company is a governmentcontractor, there are additional considerations for the project deliverables.

Within your industry there may be standards and regulations. Regulations aremust-haves that are required by law. Of course, pharmaceuticals, utility companies,and food packaging companies have regulations that dictate their practices. If companiesbreak regulations, fines and lawsuits may follow. Standards, however, are generallyaccepted guidelines and practices within an industry. Standards are heuristics, sometimescalled guidelines, which are not laws but are usually followed. The project managermust be aware of regulations and standards that affect the projects work anddeliverables.





Does the Project Have a Reasonable Deadline?Massive upgrades, software rollouts, application development, and system conversionstake teamwork, dedication, and time. Projects that dont have a clearly stated,reasonable deadline need one. Projects should not last foreverthey are temporary.Acknowledge the work. Do the work. Satisfy the user with deliverables of the project.Once youve accomplished this, the project is done.

Well talk more about project scheduling in Chapter 7, but the project managermust be aware of the project calendar and the resource calendar. The project calendardefines the hours in which the project work can take place. For example, if yourproject is to rewire an entire building with new network cable, the project calendarmay specify access to the building between the hours of 8:00 P.M. and 6:00 A.M.Resource calendars are specific to the project team members. They take intoconsideration the hours employees are available, their vacations, and companyholidays.

In addition, the project manager must consider how many working hours projectteam members will be able to devote to the project in a given day. Six hours ofproductivity is typical of an eight-hour day because of impromptu meetings, phonecalls, and other interruptions. These factors directly influence the project scheduleand if the project can meet the project deadline with the given resources.

Is the Project Sponsor Someone WhoHas the Authority to Christen the Project?Most IT folks hate politics, but we all know politics, personal interests, anddepartment leverage are a part of every company. Make certain the project sponsor isthe person who should be initiating the projectwithout stepping out of bounds.Make certain this individual has the resources to commit to the implementation andhas the support of the people up the organization chart. And do it with the fullknowledge and support of management.

The project sponsor should be an individual within the organization who has thepower to assign team members, allocate funds, and approve decisions on the projectwork. The project sponsor is typically above the functional managers of the projectteam members assigned to the project work.

Does the Project Have a Financial Commitment?If you do not have a clear sense of a financial commitment to the completion of theproject, put on your hard hat and dont stand under any fans. Technology costs







money because it makes money. The goal of a project, in the corporate world, is thesame goal of any company: to make or save money. A tech-centric project requires afinancial investment for quality hardware, software, and talent. If the project you aremanaging has a budget to be determined somewhere down the road, youve got awish list, not a project at all.

Is Someone Else Doing This Already?In large companies, its easy for two projects to be competing against each other forthe same end result. This comes back to communication among departments, teams,and the chief information officer. In a perfect world, IT projects fall under oneumbrella, information is openly shared among departments, and everyone workstogether for the common goal of a company (to make money). This process can beadministered through a Project or Program Management Office where projects aretracked across the enterprise. Of course, that doesnt always happen. You should dosome initial research to ensure your project isnt being accomplished elsewhere inthe company before you invest time, finances, and your career in it.

Possessing Multiple PersonasAre you an optimist? A pessimist? A realist? A project manager has to be all of these.You have to be an optimist so that you may lead your people, manage the resources,and implement the technology according to plan. You have to be a pessimist,secretly of course, because you need to look at the worst-case scenario for each pieceof the technology implementation. You have to be a realist because you need to lookat the facts of the projects completely, unattached, unemotional, andunencumbered.

When your project is developing, you should play devils advocate to each cornerstoneof the project. You need to question the concepts, the technology, and the time itmay take for each step of the implementation. As you can see in Figure 1-3, you shouldquestion everything before you begin.

Questions to consider:

How Will This New Technology Affect Your Users?Not all technology you implement has a direct effect on your users, but most of itdoes. Your life may be IT, but the accountant in the finance department doesnt likechange. She likes everything the way it is now; thats everything from having to click





OK on a redundant error message to installing her favorite screen saver. If yourtechnology changes her world, you should let her know ahead of time; otherwise,shell be certain to let you know afterward. Your primary objective must be to makeher job easier.

As technology has become integrated in practically all areas of an organization,users have become more tech-sophisticated. They want to know why the change ishappening, why the change is needed, and how it will help them. This brings usback to requirements gathering and communication. Ninety percent of a projectmanagers job is communication. If the project manager wants buy-in from thestakeholders, particularly the users, he must communicate the benefits and rationalebehind the technology project.

Will This Technology Affect Other Solutions?How many times have you installed software without testing it, only to discover itdisrupts something as unrelated as printing? I hope never, but it happens. You mustquestion and test the ability of the new technology to work with your current systems.Of course, if youre considering a 100 percent change in technology, then there reallyisnt a software compatibility issue.

Will This Technology Work with Any Operating System?How many operating systems are in your organization? While the goal may be justone, Id wager youve got two or three different OSs floating around. Think aboutthose graphic designers and their Macintoshes. Remember those salespeople andtheir Windows Vista laptops? And what about those mainframe and server-based




FIGURE 1-3

Project managersmust question allaspects of aproject.



Linux users? If your company has multiple operating systems, youve got to questionthe compatibility of the technology for each.

What Other Companies Are Using This Technology?The assumption is you are buying this solution rather than building it. Therefore, isit a bleeding edge solution? Are you first in line? No one likes to be first, butsomeone has to be. When embracing and implementing a new technology, ask thatquestion of the vendors salesperson. Hopefully the salesperson will be happy toreport about all the large companies that have successfully installed, tested, andimplemented the vendors product. Thats a good sign. If someone else has done it,you can, too.

Does the Vendor of This Technology Have a Good TrackRecord in the Industry?From whom are you buying this technology? Has the vendor been around for awhile and implemented its product many times over? Does the vendor have a historyof taking care of problems when they arise? This is not to say you should not buyfrom a startupevery major IT player was a startup at some time in its history. Youshould feel fairly confident that the vendor selling the product today will be aroundto support it tomorrow.

What Is the Status of Your Network Now?You may not always have to ask this question, but with so many network-intensiveapplications and new technologies today, it doesnt hurt. You dont want to installthe latest bandwidth hog on a network thats already riding the crest of 90 percentutilization. You and your company wont be happy. By asking this question, youmay uncover a snake pit that needs to be dealt with before your project can begin.

What If. . . ?Finally, you need to dream up worst-case scenarios and see if there are ways toaddress each. You need to find out how the technology will react when your serversare bounced, lines go down, and processor utilization peaks. You want to ask thesequestions and have answers for them now rather than when the crisis hits duringyour four-week vacation to Alaska.







No Other Choices?At the start of a project, in its very genesis, ensure that the proposed technology isthe correct technology. Of course, sometimes you have no control over the technologythat is to be implemented because some vice president and decision-maker heard aboutthe product from his golf buddy who is CIO at another large firm and is now havingyou install it everywhere. It happens.

Other times, hopefully most of the time, you have some input to the technologyimplemented to solve a problem. You are the professional, the IT guru, so youshould have a definite say regarding the technology that youll be in charge ofdelivering. Youll need to create a list of questions and then find the appropriatetechnology that offers the needed solution, works with your current systems, andfits within your budget. Having the right technology to begin with ensures successat projects end.

Interviewing ManagementTo have a successful project, you need a clear vision of the delivered result. You needto know why the project is being implemented. You need a strong commitment ofmanagement to the project. You need to share managements vision of how the endresults will benefit the company. How will you discover these facts? Ask!

When your boss comes to you, for instance, and reports that you are to managea project to upgrade the mail servers, you need to find out why. It may not be thatthe manager really wants the mail servers upgraded; he could just be having troubleopening a cartoon his frat brother from Utah sent him and be blaming it all on thecompanys e-mail system.

When you approach management to find out why the project needs tohappen, you arent questioning their decision-making ability. You are, however,questioning what their vision is for the project. In your company, yourimmediate manager may be the most technically savvy genius in the world, andher decisions are always right on target. In others, if not most, managers knowthat a technology exists and can be implemented. However, they dont knowexactly which technology theyre after. Figures 1-4 and 1-5 show the differencebetween effective decision-making abilities and poor decision-making abilities.








FIGURE 1-4

Well-informeddecisions result insuccess foreveryone, notjust the project.

FIGURE 1-5

Decisions basedon complaints,wishes, and salesspiels miss themark.



As the project manager, your job is to ensure the success of your project andyour career, and to ensure a successful impact on the bottom line. When you speakwith management about the proposed project, you are on a fact-finding mission.Ask questions that can result in specific answers. For example,

What do you want technology so-and-so to do?

Why is this technology needed?

How did you discover this technology?

What led you to the decision this was the way for your company to go?

Sometimes a manager may come to you with a specific problem for you to solve.In these instances, the project is wider and more open-ended, and youll have todrill deeper into the problem presented. Lets say for example that a vice president iscomplaining about the length of time it takes her to retrieve information on customersthrough your database. She just wants it faster.

Your questions may be something like this:

Can you show me how the process is slow?

Is it slow all the time or just some of the time?

How long have you experienced this lag?

Have others reported this problem?

There are several things we can do to increase the speed of the process. Eachmay require a financial commitment initially but would result in fasterresponses for all of the database users. Do you want to investigate this route?

Notice how youre thinking like an executive. Its not technology for technologyssake. A new multiprocessor database server, gigabytes of memory, and faster switchesare all cool stuff, but if they dont earn their keep, they are just toys. When you areinventing a project, think like an executive of a company and show how theinvestment in software, hardware, and talent can create more dollars by increasingproductivity, safeguarding data, or streamlining business processes and ultimatelymaking customers happy.

Your company may shift much of these requirement-gathering duties to a businessanalyst. Thats fine, but you and the business analyst should still work together toexamine the goals, requirements, and objectives of the project that will eventually






feed into your project scope. One approach that Ive always liked is called SMART.For each project goal, you can determine if it meets all of the following to spell smart:

Specific You to know what the specific requirements and deliverables are foryour project.

Measurable Its a good idea to avoid vague terms like fast, good, and happy.You need measurable metrics for the project requirements.

Achievable The goals of the project should be achievable considering theresources, cost, and time required versus whats available in the organization.Management and customers that ask for a long list of requirements withoutproviding a balance of time and monies are setting themselves up fordisappointment.

Relevant The goal of the project shouldnt be for someones private agenda.The goals of the project should support the primary business need of theorganization, provide an opportunity for the company, or solve a problem.Basically, all projects should either increase revenue or cut costs.

Time-bound Requirements that are dreamy, are open-ended, and dontprovide an easy link to conclusion arent good requirements to accuratelyplan and create.

Interviewing the StakeholdersAs you know, stakeholders are individuals, groups, or organizations that have adirect interest in the outcome of the project. Your projects success or failure willdirectly affect the way they complete their work, use their existing technology, orcontinue to buy from your company. Stakeholders can include

Management

The project manager

The project team

Project sponsors

Customers

End users

The community






In a technical project, the largest group of stakeholders is typically the users. Anyproject that has an impact on users needs to be discussed with them. This can bedone in several different ways. The most popular, and sometimes most disruptive, isa focus group. Focus groups are often led by a professional, impartial moderator andare conversational in tone. Fair warning: if you dont have a good moderator that willdirect the conversation to productive input, you might find that focus groups have atendency to engage in gripe sessions about the problem rather than the solution. Ifyou choose this route, take control of the discussion and keep the participantsfocused on the solution.

A focus group allows you to take a sampling from users from each affecteddepartment, present the project to them, and then listen to their input. You need toexplain how the proposed technology will be better than the current, how it willsolve problems, and, if necessary, why the decision is being made to change. Inputfrom focus groups can alter your entire project for the good or the bad.

Another way to interview users is through an intranet site. This method can be aneffective form of communication because users have the opportunity to share theiropinions and have some say on your project. Of course, with this route, its best tohave your intranet site request responses to a survey so that the results can be talliedquickly. See Figure 1-6 for an example of an online survey.

Some project managers rely on the Delphi Technique. This approach is oftenused in risk management, but it can be applied to any consensus-gathering activity.The participants and their comments are anonymous. The participants are allowedto freely comment on the technology, their concerns, and their desires for therequirements. All of the comments are then shared with all of the participants, andthey can agree with or discount them according to their opinions and experience.Because the process is anonymous, there is no fear of retribution or backlash, orof offending other participants. After several rounds of discussion, a consensus isformed on what is needed. An intranet site can automate the method and keep usersanonymous.

Finally, learn how the users do their work now. This is especially important forsituations like new software development, application upgrades, and new hardwaretechnologies. This can be accomplished in a usability laboratory where mockscreens, resembling the technology being implemented, are made available. Feedbackfrom users helps design the solution to be implemented. By working with a userone-on-one, you can experience how the user is using the current technology, howthe new technology will affect the user, and what the ultimate goal of a technical







change should be: increased productivity and increased profits. Dont lose sight ofthat fact. This is really stakeholder observation, and it comes in two flavors:

Passive observation Where the observer simply observes and documentsthe work and does not interact with stakeholders at all. Its sometimes calledinvisible observation.

Active observation Where the observer interacts with the users, stops theirwork to ask questions, and can even get invol