The Project Manager’s Cycle

“What does a project manager do?  What value do you add to my project?”

This begins a series of posts on The Project Manager’s Cycle.  That is, those activities the PM performs every reporting cycle – the Monitoring and Controlling activities of the PM.  I have always worked on a one week reporting cycle, but some environments operate on longer cycles, such as two week cycles and monthly cycles.  That said, I believe that the more frequently this cycle is repeated, the more consistent the results.

Since this set of activities is a circle – when the last step is completed, it starts over at the beginning – “beginning” and “end” are purely arbitrary.  I document the cycle as starting when the project performance metrics are posted (e.g., if team members have to post their hours by Friday afternoon, then the cycle starts when those results are available to me).  I have worked with MS Project with Sharepoint and EPM and Clarity (formerly Niku) Workbench.  I’ve also worked in environments where these metrics are just not available, which requires some flexibility.  Sometimes, you just have to make do.

The Project Manager’s Cycle includes these activities:

·         Validate the metrics

·         Validate task status

·         Incorporate approved change control

·         Reschedule/Replan

·         Check variances and progress/productivity

·         Communicate planned/expected resource utilization to resource managers

·         Develop earned value reports

·         Review risks and mitigation actions

·         Review issues and action items

·         Review commitments and action items

·         Conduct client/sponsor status meeting

·         Conduct project team meeting

·         Publish the project status report

This list doesn’t show dependencies.  Some of these activities can (and should) be conducted concurrently, while others are dependent on prior activities.  Over the next baker’s dozen posts (or so), I’ll go into detail on each of these Project Manager Cycle activities, including its importance, its dependencies, why I show them in this sequence, and the detail of what each activity includes.

Well, the ferris wheel is slowing down, ready to start loading new passengers.  I invite you to join me on this ride as we circle the cycle.

Going Dark

“I’m twenty-five percent complete and on schedule,” reported Peter at the end of the first week of his four week task.  A week later, Peter reported “I’m fifty percent complete and on schedule.”  Some foreshadowing was offered in Peter’s report at the end of week three: “seventy-five percent complete, but I have some other things competing for my time next week.  I should be able to catch up, though.”  Then the bomb dropped on Wednesday, just three days later, when Peter finally had to face his deadline.  “It’s going to take me three more weeks to complete this.  I was going to use the API in the new version, but it’s returning the data in the wrong format and the vendor doesn’t have a patch, so I’ll have to rewrite it to use the old API and …”

I believe the phrase “going dark” originated with Jim McCarthy in Dynamics of Software Development (Microsoft Press, 1995).  As a guide for managing programmers, this classic is valuable still.  Rule number 30, Don’t Go Dark (pp 102-106), describes the hazards of failing to get regular, frequent, concrete evidence of a developer’s progress.  In this age of Agile, Scrum, RAD, RUP and other TLA methodologies, we project managers still allow team members to do this to us.  And not just in software development projects or by programmers.

There may be several different reasons to explain why a team member goes dark.  Maybe they don’t understand how to complete the task nearly as much as they thought they did.  Maybe they have 15 other things to do and this isn’t (from their perspective), the most important.  Maybe they don’t find the task as compellingly interesting as something else they can work on.  Maybe it’s a passive-aggressive way to make a point.  Often it is some combination of these – a less experienced team member, slightly over their head and with a seemingly endless list of must-haves from other managers, so they focus on doing what they can do rather than committing the time that’s needed to focus on this task.

It could be just the opposite, a team member who thinks they know how to complete the task and spends endless time searching false leads and dead ends without converging toward the solution.  For whatever reason, it needs to be recognized and addressed.  Fred P. Brooks, Jr., in The Mythical Man-Month (Addison-Wesley, 1975) documented the consequences of even slight slippages.  “How does a project get to be one year late” he asked.  “One day at a time.”

Regardless of why it may happen, appropriate planning and control protect us from these consequences.  A key task should have one owner, be no more than two weeks duration (about 65 effort hours if the owner is dedicated), and have a clearly defined Done state (see my previous entry).  That covers “appropriate planning.”  Appropriate control is to have an early warning system (which I will discuss in a future post) for when a task will be delayed so the delay can be addressed and corrected before it is a project problem.

Have you had a team member “go dark?”

The Task

“Is the PaRC Coding task complete?” asked Evelyn, the PM.  “Yes,” responded Jeff, one of the best programmers, who then continued “I completed all of the coding yesterday.”  “But what about the unit
testing?” Evelyn followed up.  “No, I’ll get to that tomorrow,” replied Jeff.  “But the task includes coding and unit testing,” Evelyn noted exasperatedly.  “It isn’t done until both are done and it’s ready for turnover to the test group.  You know that.  Why do you tell me it’s done?”

I’m trying to build some of the context for presenting best practices, but PM best practices are difficult to document, in this case, because everything is so integrated.  You can’t really discuss one thing being a “best practice” until you have a context for that practice to be best in.  For example, you can’t comprehensively discuss estimating without also including risk management.  You can’t discuss reporting best practices without addressing stakeholder management.  You can’t address acceptance management without addressing scope management, which also has to involve change management.

So I’m going to start with a fundamental and see if I can build a base sufficient to start expanding into more complex topics.  The Work Breakdown Structure (WBS) is a core project management document and the task is the atomic element of the WBS.

Typically a task should be a single component of work delivered by one person.  This would generally be a best practice.  I have frequently made exceptions to this practice, but that doesn’t prevent this from being a best practice.  And knowing when to make exceptions is part of the pragmatic, flexible responsibility of the good PM.

The task should have clear transitions.  The inputs, outputs, and hand-offs (in- and out-bound) should be clearly understood.  This is one of the main areas where I frequently experience problems, when I assume that team members clearly understand their tasks, including Done.

I’ve developed some techniques to address this problem.  PMBoK v4 references the WBS Dictionary, what used to be called the task dictionary.  The WBS dictionary is without question the appropriate reference for this situation.  But who has the time and budget to include one in the project?  What I’ve found that I can do for key project tasks is sit down with the task owner (Owner A) and the owner of the next (successor) task (Owner B).  In this facilitated discussion with Owner A and Owner B, we discuss what is included in the task, what is expected as inputs and outputs, and what constitutes done.  This often identifies differences in expectations by the owners which, without the conversation, would’ve left  some ball dropped.

The key point I make sure to include in the discussion:  Owner B has to accept the results before the task can be closed for Owner A.  Universally the task owners know more about their jobs than I do, so I don’t have to impose the general task scope, all I have to do is make sure each successive owner is clear about the task boundaries.  It’s amazing how many problems this little discussion has prevented.

Call it a dynamic WBS Dictionary, maybe.

Do you have any experience with a WBS Dictionary, or problems with not having one?

A Philosophy of Projects and Products (Part 3 of 3)

“We’re on schedule for development and plan to start testing next week,” an upbeat Dave updated his manager, John.  John answered, “That’s good, but you’ve pulled developers from support to work OT to make the schedule, our support backlog is climbing, and now no one is available for the scheduled maintenance upgrade this weekend.  We need to take a closer look at how you are deciding the team’s priorities.”

Over the past two blog entries, on P&SD PM and Consultancy PM, I discussed two distinct project management philosophies.  This entry will discuss why this is important to a project manager, to a company hiring a project manager, to a company engaging a vendor of PM services, and to a supplier of PM services.

One area where the distinction is important is academia.  In some circles there are efforts to create a distinct School of Project Management separate from the School of Management.  Existing Management leadership resist this effort, answering that PM is just a variation of Management, not a distinct discipline.  Looking at P&SD PM, one could argue that P&SD PM is, as they argue, just a variation;   after all, it is generally found in organizations where PM is not a core competency, it serves the delivery of the organizations primary function, and general managers manage and utilize the PM services.  Consultancy PM, on the other hand, is a distinct model of management;  it doesn’t support an organization, it is the core competency of the organization.

Another area, closely related, is PM research.  Little of the published research on project management, such as that in Project Management Journal, distinguishes among the types of project management being practiced and the results of the research.  But what can be accurately inferred from the research when comparing such distinct practices as I’ve described in the two previous entries?

More relevant to the practicing project manager, especially one considering a career change, are the styles, cultures, practices, and expectations within organizations with the different PM environments.  I’ve worked in both types and management expectations are crucially different.  Further, the people – your managers and peers – in one are not likely to recognize the differences and prepare you for the changes.

As Peter M. Senge discusses in The Fifth Discipline: The Art & Practice of the Learning Organization (Doubleday, 1994), our mental models can artificially restrict our performance.  Be prepared when moving from a P&SD PM culture to a Consultancy PM culture, or vice versa, to let go of restrictive workplace assumptions.

Finally, the PM Best Practice blog endeavors to advance organizational maturity and continuous improvement.  The concepts explored in the P&SD PM environment and the Consultancy PM environment will be regularly revisited in future columns.  PM best practices are different in these environments and trying to force a set of best practices appropriate for one onto the other is, at best, frustrating.

Do you see other significant ways that the P&SD PM and Consultancy PM environments are relevant to you as a project manager?  If you’ve encountered any of the cultural differences that I describe, how did you adjust to them?

A Philosophy of Projects and Products (Part 2 of 3)

“How are you fitting in?”  Tom, the Account Manager, was conducting the three-month review with Eric, PM trainee.  “I can handle the technical aspects of the job OK,” Eric answered, “but the culture is very different.”  Eric had jumped ship from one of the clients and had joined the consulting firm for the opportunity to travel.  “My old job was all about fixing the applications.  You focus on the numbers more than we ever did.”

This is the middle of a three-part series taking an uncommon perspective on the Project Management environment.  The first entry discussed the characteristics of the Product & Service Delivery PM environment.  This entry discusses the Consultancy PM and the next entry concludes the series by reviewing the impact and significance of this subject.

The Consultancy PM is usually found in the big consulting houses:  PWC, Deloitte, Accenture, E&Y, KPMG, Tata Consultancy, etc.  The core competency of the Consultancy PM is project delivery, independent of domain, product, or service.  Whereas the P&SD environment will apply lessons learned to improve the product or service, the Consultancy PM applies lessons learned to improve project delivery.  The Consultancy PM focuses on stakeholder management, risk management, change management, and acceptance management.  Metrics concentrate on cost management and Earned Value Management (EVM) is common in Consultancy PM.  Product or service metrics are rare.

The Consultancy PM will be more attuned to deliverables rather than milestones, cost is prioritized over schedule or scope, resources are valued for their skill producing deliverables, and resources are generally exclusive to a project for the duration of their assignment.

Consultancy PMs could also be called Assembly Line PMs.  This shows the continuing evolution of the PM function, from journeyman PM, to craftsman, then to manufacturer.  In this case, the Consultancy PM aspires to complete projects like a company runs an assembly line.  In this case, however, the product or service – the target of the project – is a black box to the Consultancy PM.  Think of it like cans coming off an assembly line.  Except for the label, each can should be identical on the outside, but the content of each can could be different.

PMI’s Organizational Project Management Maturity Model (OPM3) aligns best with the Consultancy PM.

Small consulting firms offer an interesting mix across these descriptions.  Some, for example, specialize in a particular product or service, operating in the P&SD model;  others are immature, competing on price, mostly clueless about the needs for PM maturity, thus operating as journeymen;  then there are the second-tier consulting firms – they aspire to join the big leagues, but don’t yet have the volume and lessons learned loop so that their assembly line is not yet operating with the smooth efficiency of the top-tier players.  For those interested, this series of articles will help identify which model describes a particular consultancy you might engage.

Are you familiar with P&SD and Consultancy PM environments?  What other characteristics describe and differentiate them?  Can you use these models to improve negotiations with consulting firms?

A Philosophy of Projects and Products (Part 1 of 3)

Ron, the IT Director, was meeting with his managers.  “Phil, what is the status of the SAP implementation?”  “The PWC consultants are on schedule and on budget.”  Ron, looking across the table at the manager over the imaging applications, then asked, “Allison, how is the new fax/OCR product?”  “Ron, I wish this Brand X consulting firm we selected was half as good as PWC at schedules and budgets, then it would almost be worth it to continue using them. I’m going to have to continuously monitor their progress, but we should probably plan for a 100% overrun,” she replied.  Finally, to Dave who manages the finance applications, he asked about that status.  “We’re staying ahead of the vultures, but the primary focus is keeping the lights on and responding to the support calls.  We are running about normal on resourcing for maintenance and enhancement requests,” replied Dave.

This begins a three-part blog series on a rarely discussed but rather significant split in the way to look at project management.  The first two entries will take a look at PM from two common perspectives, then the final entry will address the impact and significance of this subject.

The PM environment I’ll discuss in this entry I’ll call Product Delivery (more accurately, Product & Service Delivery).  This is the classic craftsman model where process (and people and tool) maturity is used to enhance and optimize delivery of products and services.  This model is evolved from the journeyman, for whom every new creative effort is a original challenge.  By applying knowledge from lessons learned, best practices and risk management, delivery becomes more consistent, reliable, and predictable.

The core skill of the Product & Service Delivery (P&SD) organization is managing the product or service, their priority is product and service availability, and metrics focus on the product or service (i.e., PM practices are measured to produce more products, faster, for less cost).  Other characteristics of P&SD include a preference for milestones over deliverables, generally prioritizing scope over schedule or cost, resources (including PMs) are valued for their domain knowledge, and resources are generally shared between projects (new development) and maintenance/support.

Most IT organizations, for example, operate with this model and call what they do Project Management;  after all, they use processes and methodology modeled on the Project Management Institute’s (PMI’s) A Guide to the Project Management Body of Knowledge (PMBoK).  They may even have a Project Management Office (PMO) to drive PM best practices. 

The maturity model best aligned with Product and Service Delivery is the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI).