Josh Nankivel wrote a chapter in Project Pain Reliever recently, that addresses one of the most common problems that newer PMs face - being overwhelmed with the size and scope of the project they are trying to manage. The key, of course is to break the larger project idown into smaller chunks that can be dealt with more effectively.
Here is an excerpt from the book and a quick video that Josh put together on the subject. Hopefully it will help someone you know who is "stuck in a scary place" from a management perspective.
You have been trying to figure out how to manage a huge project. There are so many moving pieces that the complexity can become confusing. The path forward is murky and there’s a sense of unease about what is com- ing up. You don’t think that you can manage this project without splitting it up, but you don’t know how to do that.
You might think that the signs of this problem are simply a feeling of unease in your own mind, and you certainly shouldn’t ignore that feeling, but look for the following signs:
• The team is uncertain of what they should do, even though you have told them the grand vision many times.
• Although you are using good scheduling practices, your schedule keeps changing as you add more work that was not in the original plan.
• You find your team members doing tasks that are not on the schedule because they know these things need to get done when they pop up. Some of them are even emergencies.
• You don’t have a good view of the project status as a whole, and you aren’t sure how to answer the question “How is it going?”
What will happen if I do nothing?
You could continue to “keep the faith” in your project schedule, even though it seems to be changing weekly with additional tasks that really need to be done, but that were not in the original plan. You could tell yourself that this always happens on projects and there is no way to avoid it. Blind faith in a project schedule is not virtuous though; it is insanity.
The problems will get worse over time, and eventually management may lose con- fidence in your ability to manage the project. You won’t be able to produce confident estimates to completion due to all the uncertainty and change. They may decide to replace you with someone else, or shut down the project entirely.
This is what happened: You tried to define how your project would get completed be- fore you were clear on what you were doing. What you need is to define clearly what you are delivering. Delivering...that’s catchy. You will also need to break these deliver- ables down into manageable pieces, so this isn’t so overwhelming and confusing.
This chapter shows you how to get there.
What should I do?
Breaking down the work in a project works best with a process designed to keep you from messing it up. Be sure to include your project team, key stakeholders, and other subject matter experts in this process.
5(a) Start with big nouns.
Start with the high-level requirements of your project. These are the objectives that describe the “end state” you are trying to achieve. There will be a handful of major deliverables, not verbs but nouns. For instance, a task might be “build system X” but the deliverable is “System X.”
You can do this process in outline form, with an organizational structure-like hi- erarchy, using mind-mapping, or whatever works best for you. The key functionality you need is to build a hierarchy of all the deliverables. This hierarchy is called a work breakdown structure.
5(b) What makes up the big nouns?
Next, take each of the high-level deliverables and ask: “What are the smaller pieces that make up this big task?” Notice we did not ask, “What work will it take to pro- duce these?” - that question comes later on. Get crystal clear on what you are deliv- ering before thinking about how you will do it.
For instance, System X is probably composed of several subsystems. Let’s call them Subsystem A, B, and C. Each of these subsystems has a unique functionality, and System X needs all of them to do its job.
5(c) Keep going!
Each subsystem is likely made up of a collection of modules or packages, which in turn are made up of procedures or functions. The specific products and sub-prod- ucts are going to be context-sensitive to what you are creating with your project.
Stay focused on nouns and what these deliverables are made of. It is human na- ture to jump right into how, so be careful to redirect the team towards nouns when this happens. Keep them focused on what.
5(d) When do I stop?
It depends. Wherever you stop, the lowest points on each branch of your work breakdown structure are called work packages. This is the transition point where the product (what) helps shape and is integrated with the schedule (how, who, when, where).
For discrete deliverables that have a clear start and finish within the life span of the project, you will get to a logical stopping point, which is usually in the 20-=-80 hours of effort range. If your breakdown, at any step, seems to be arbitrary and not a true reflection of the product(s), it may be a sign that you have gone too far.
For activity-related deliverables of a service of some kind, there is a different ap- proach available. For instance, configuration management is a service you will pro- vide in some way throughout the life of your project. It doesn’t have a discrete start and completion within the project life span. In this case, break the “configuration management” service deliverable down into the individual or groups of services pro- vided. In this case, some examples may include Configuration Management Board, Document Management, and CM Process Improvement.
5(e) Then what?
Now that you have a clear idea of what your product is, you can tackle the other questions with confidence, such as “What work will it take to produce these?” De- pending on the type of project, you probably want to allocate the high-level re- quirements down to lower levels in your new work breakdown structure. Then, with a clear idea of what “done” looks like, it is time to identify the tasks that will be completed in order to deliver each of the work packages.
Find more in the Project Pain Reliever book and in the video below...
Steve Denning, author of, “The Leaders Guide to Radical Management”, gave the keynote address at the Scrum Gathering in Seattle a few weeks ago. He talked about the corporate experiences he had early in life and how they led him to define what he sees as the way businesses should operate from here on out. Many of these ways are very "Scrum-like".
He boiled it down in a very simple way, by saying there are only 2 kinds of organizations out there - those that delight their customers and those who do not. The ones that delight their customers have employees fully engaged as self-organizing teams. Amazon, Apple, Salesforce are familiar examples of these delightful organizations.
He goes on to describe traditional management practices that are management focused, rather thatn customer focused. There he outlined a fundamental tension between management and employees, based on the failure of traditional management methods.
- There is always a push for volume and a push for quality. These are often fundamentally at odds.
- Traditional management pushes for “more”. It focuses on more of the programs that management defines, rather than what the customer wants.
Five Planks of Traditional Management, according to Denning, are:
- The purpose of an organization is to produce outputs.
- The purpose of management is to do this efficiently.
- Customers are “demand” that can be manufactured.
- Staff are “human resources” that can be manipulated.
- Traditional management practices are a success and contrary evidence is inadmissible.
These feel a bit cynical, but many of us would agree that they generally ring true.
Five Big Shifts in Management Style Denning sees as needed are
- A new goal for the organization – from producing stuff (outputs) or making money for shareholders to delighting customers (experiences).
- A new role for managers – from controller of individuals to enabler of self-organizing teams.
- New coordination Mechanisms – form heirchical bureaucracy to dynamic linking (iterative, client driven work)
- Shift from value to values – from economic value to values that will create customer delight (transparency is key)
- Interactive communications – from command and control to adult to adult conversations.
You will see that a lot of these are very Scrum-like at their core. If your organization adopted these principle tomorrow, Scrum would be an easy fit as an approach for getting just about anything done.
So how close is your organization to adopting these principles (or something like them)? Has any one of these shifts happened where you work?
I'm at the Seattle Scrum Gathering 2011, listening to Mike Cohn talk about self-forming teams. He was talking about how early in his career he wanted a promotion to Project Manager. His boss would tell him, "Act like a PM and I'll make you a PM." This apparently seemed like a reasonable approach until Mike realized that there were no PM openings and there wasnt even the opportunity to take on a PM-like role within accessible parts of his organization.
So for Mike there was no "gap" - no vacuum to fill and make a difference. If there are no gaps there is little opportunity for growth and advancement. Mike suggested that you intentionally create "gaps" that you expect team members to fill. Then you just step back and see if they do.
Is this something you practice in your organization? What do those gaps look like?