 |
Home > Detail: Are Your Pants on Fire, or Do You Suffer from Split Focus?
| A StickyMinds.com Original |
| | |
Are Your Pants on Fire, or Do You Suffer from Split Focus?
By Johanna Rothman
   
Summary: Some schedule games--Split Focus and Pants on Fire--are the result of your management not making certain decisions about the project portfolio. Without those decisions, your project has problems. In this column, Johanna Rothman explains what you can do when the problems on your project are caused by your management’s lack of decision making. | | |
|
|
 |
 Hear more about this topic in the StickyMinds SoundByte podcast interview with Johanna Rothman.
Imagine you're working on or managing a project. You're dealing with risks and making technical decisions--pretty much humming along. The project isn't easy, but you're making progress. One day, you arrive at work and your boss says, "Stop working on that project. Work on this one instead." You do. A week later, the same thing happens--you stop working on the second project and move on to the third. Welcome to the Pants on Fire schedule game.
Pants on Fire is bad enough, but some managers don't even let you work on just one project at a time. You may have had a boss like one of mine who said, "I'd like you to spend 50 percent of your time on project A, 35 percent of your time on project B, and 15 percent of your time on project C." You and I both know there's no way you're making progress on projects B or C, but they do successfully split your focus off project A. The multitasking you're doing is the Split Focus schedule game.
Split Focus, the multitasking schedule game, and Pants on Fire, the flip-flop priority game, have similar causes: Your managers can't or won't decide which project is most important right now. Making those decisions is tough, and some managers don’t know how to decide.
People who have been working in the software industry for more than three weeks have probably encountered these two pervasive schedule games. Both of these schedule games cause context-switching for the project team members--including the project manager--and will slow your projects, sometimes to a crawl.
But what should you do if you're a project manager or technical lead and you realize your management is causing most of the problems on your project? Prayer might be helpful but is not enough. Here are some actions you can take.
Start with an Agile Approach
If you're not already working in short (one- to two-week) timeboxed iterations, implementing by feature and integrating as you go, start that now. One of the reasons your managers might have such a difficult time selecting the most important project and keeping people on it is that they don't know when you'll be done with your project. With timeboxed iterations, you can show them how far along you are at the end of the iteration, and you have a better chance of predicting when you'll be done.
Say your organization needs to release something in six months, but you won't be done for eighteen months. You might be able either to release something from this project in six months or to put this project on hold until you've completed another project in six months or fewer.
Know What "Done" Means
Make sure you're doing the minimum required. Sometimes your managers will use Pants on Fire to move people off one project that they think is complete enough. If you haven't defined release criteria, do so now. Make sure everyone understands what "done" means for this system.
Estimate with Ranges
Sometimes managers invoke Pants on Fire or Split Focus because the team missed its estimate for project completion. Instead of only providing one date for project completion, try providing a range or a confidence level with different dates. Say to your manager, "I have a 70 percent confidence we can meet June 30, and a greater than 95 percent confidence we can meet September 15," and you'll have a different conversation about when to stop this project and start another one.
Build a Project Portfolio
If you've already taken these steps and your management still wants to have your project team multitask or switch projects frequently, then it's time to show management what everyone is doing in a project portfolio. Once you have a portfolio, you can analyze it to see which projects are at which priority.
To build a portfolio, first collect the list of all the work for all the people who are being shuffled from one project to another. Remember, it's the list of project work, ongoing work, periodic work, ad hoc work, and management work.
Organize all that work in a grid, with months across the top and the list of projects down the side. Use the estimated start and end dates for each piece of work, so it's easy to see when you think the work will start and end.
Once you've got the list, try to rank the projects. That means assigning a unique number--1, 2, 3, 4, and so on--to each project. The highest-ranked projects are the most valuable to the organization. Discussing a ranked list with your manager might help you have a more productive conversation than if you just discuss a list of projects.
Qualitatively Evaluate Each Project
If you don't know the value of each piece of work, use these qualitative questions to evaluate them:
- How does this project fit in with all the others?
- What is the strategic reason for this project?
- Is there a tactical gain from completing this project?
- To make this project successful, are we ready to adequately fund it?
- To make this project successful, are we ready to adequately staff it?
- Do we know what success looks like for this project?
Sometimes a qualitative evaluation isn't enough, so you might need to use numbers to evaluate the projects.
Quantitatively Evaluate Each Project
If your managers can determine the strategic and tactical goals for this project, it's time to see if the money you'll spend on the project will gain the organization any return. The return you gain may not be in revenue; it could be in the ability to release products faster. But if there's no quantitative or qualitative return, you and your managers need to decide if this project is worthwhile.
- When will we see any monetary return from this project?
- What's the expected revenue curve for this project?
- What's the expected customer acquisition curve for this project?
- When will we see retention of current customers from this project?
- What's the expected customer growth curve?
- When will we see a reduction in operating costs from this project?
- What's the expected operating cost curve?
Answering these questions isn't easy, but it is necessary.
In Closing
When your project's problems aren't caused by something you and the team are doing, it's time to dig deeper. If you feel as if you've got whiplash from all the project changes, build a portfolio and discuss it with your management. What have you got to lose?
About the Author
Johanna Rothman is a management consultant and a regular StickyMinds.com and Better Software magazine columnist. Johanna is the author of Manage It! Your Guide to Modern, Pragmatic Project Management, as well as the coauthor of Behind Closed Doors, and the author of Hiring the Best Knowledge Workers, Techies & Nerds. She is a host of the Amplifying Your Effectiveness Conference. Johanna has presented at STAREAST, the Better Software Conference & EXPO, and Applications of Software Measurement & Management conferences. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.
Back to Top
StickyMinds.com Weekly Column From 10/01/07
|
