This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
At one point, euphemistically referring to troops as "resources," McChrystal writes, "Resources will not win the war, but under-resourcing could lose it." Another way to reads this sentence is: Under-resourcing could lose the war, but more resources won't necessarily win it, either.
Calling Bullshit on Project Management 2.0 -- OK. I've got your attention with my over the top title. Sorry about that.
Actually, over at Glen Alleman's Herding Cats: Top Down / Bottom Up = Project Management 2.0? Not with this approach, he doesn't so much call bullshit on PM 2.0 but rather on an unconvincing setup and payoff of someone else's promotion of the idea that purports to blend the best parts of "traditional" (for want of a better word) and "agile" PM.
I can't stand it when the presentation of good ideas are ruined by poorly developed logic and arguments promoting them.
Magic Numbers - Project Management -- From Scott Berkun, The magic numbers of project management, an exploration of some of the games played with estimates.
One of the things he doesn't mention in the "what to do instead" section is to make the estimation process a conversation and the open use of range estimates (buffers) for the project as a whole. This takes the pressure off of everybody to come up with [the impossible] accurate estimate.
MS Project 2010 Unveiled -- ComputerWorld reports that MicroSoft has opened up on the next version of MS Project, the application we all love to hate. It's apparently picking up the "ribbon" interface that has me still re-learning how to do things in Office 2007.
Brian Kennemer at Projectified is highlighting some of the features, including a Team Planner and a Timeline view. I'm sure he'll be coming out with more.
My big questions are whether they're fixing the print function so it's more intuitive about what'll show up on a page without going through multiple iterations of Print Preview, and, more important, if the scheduling engine will let you level resources BEFORE identifying a critical path.
Creator vs. and Revisor -- OK. I'll admit it. As a project manager for creative endeavors, concerned with keeping the effort moving toward promised delivery dates, there's the occasional frustration with multiple reviews and revisions impinging on the schedule. Sometimes (?), even after the one or two or three contracted revisions and "final approval" has been granted, there's someone else who has a better (or maybe just their own) idea for a minor tweak to a few words or to the position or color of an image on a website.
Or sometimes, during the original production of the deliverable, the original copywriter or designer is of the perfectionist bent. Where I see output that is "good enough", the "creator" has changed role to become "revisor", as described in a recent Engines of Our Ingenuitypodcast(transcript)...
"There’s a scene towards the end of the 1984 movie Amadeus where an impresario demands that Mozart finish the opera he promised. "Oh, it is finished," Mozart replies. "Up here," he says, pointing to his forehead. "The rest is just scribbling."
"And that’s our "genius" fantasy, isn’t it? Einstein, poring over dreary patent applications while working out the theory of relativity in his head. Mozart, taking musical dictation from God, as a pathologically envious Salieri imagines it in Amadeus. The perfect product is somehow out there in the ether, perfectly finished at the cosmic factory. We just have to find it -- the rest is just scribbling.
"But it rarely works that way. Maybe it never works that way. A creator may work at a white heat, but there’s a cold shadow by his side. Let's call the shadow "Revisor." Revisor has no first thoughts, only second thoughts. Revisor also has a terrible case of OCD. He's always asking the same question: could it be better?"
"Could it be better?" Of course it could. Everyone involved askes that question throughout a project. But assessing and defining the incremental amount of "betterness" versus the impacts on the budget and schedule of the project are sometimes non-trivial exercises.
The thing is, though, my frustration is usually only a short-term exasperation and actually can serve a purpose. It gives me something to whine about so people keep it in their head that we're managing schedule and effort/budget as well as the quality of the product. (Although when (usually) the tweaks come from the client side, I don't whine too loudly. Just enough to lay some subtle guilt on the "revisor" through hints that these are unexpected changes and that there is not necessarily zero impact -- unless, of course, they are so significant that a scope discussion is triggered.)
Actually, if the project is appropriately sold, and expectations are realistic, the classic project management dilemma of delivering top quality versus delivering profitably and on time rarely ever really kicks in if I've been able to set up the project with appropriate schedule risk buffers. But that's a subjectI've touched onbefore, many times.
So, Mr. or Ms. Revisor -- revise on toward perfection. I'll let you know when you might be causing problems and have to start considering what's "good enough".
Why requirements stink - "Requirements suck for two major reasons. 1. Requirements is not Design... 2. Too many cooks."
Waste in requirements - Asks "how do useless (?) requirements get into systems when...many important features are never implemented?" Relies on good comment thread to approach an answer.
How to align stakeholders around project scope without a requirements review and sign-off process - A few months ago I posted about how requirements walk-throughs are a necessity in any good requirements development process. I’m here today to tell you I’ve changed my opinion. It’s not that walk-throughs lack value. They definitely do. But the timing, scope, and methods of these reviews might need to be reconsidered. A structured requirements walk-through is not always appropriate...
Requirements Walkthroughs - A response to the previous link about eschewing reviews and sign-offs. (...and my source for that link. Thanks, Craig.)
Here they come again with what may be one of the most quoted useless set of statistics. The Standish Chaos Report 2009 is out. And guess what?
More projects than ever are "failing". (There, you don't have to go to the link.)
The mind boggles imagining the flurry of activity in consultants' offices around the world, updating their PowerPoint presentations, websites, and blogs.
Project Management: Multiple Personality Disorder Required -- Good piece over at ProjectSteps: Project Management Paradox, which goes into some of the rocks and hard places that [project] managers find themselves between when doing their thing. It's based on Tom Peters' old book, Liberation Management - a good one - my old copy is well worn. Some of the dilemmas to be navigated include
Total Ego versus No Ego...
Autocrat versus Delegator...
Leader versus Manager...
Oral versus Written Communication...
Complexity versus Simplicity...
Big versus Small...
Patience versus impatience...
Linkage: Johanna and Esther -- You may have noticed a core group of blogs and sites that I tend to link to. Obviously they are the one's I read. In addition to Glen Alleman, two of my regular go-to gals (so much for PC) are Johanna Rothmann and Esther Derby. Here's a pile of posts from them that are worth your time.
From Johanna Rothmann:
Why Everyone Needs to Manage Their Own Project Portfolio - "...Developers (and testers and writers) need to let go of old work. Their managers need to stop assigning everything that smells like that old thing to those specific developers, and add in the new requests to the entire project portfolio....The key is for everyone to know what they are working on for a short while, and what their personal backlog is..."
Measuring Productivity: More Difficult for Managers - "...how to measure knowledge workers. For software project teams, it’s easy: the number of running, tested features over time. The features have to be complete. No partial credit for partially done features. But what about for managers? That’s a little trickier..."
Which Kind of Project Are You Working On Now? - "...Especially in this economy, I would do as little as possible on keep-the-lights-on projects, avoid normal growth, and see if I couldn’t transform my business. But that’s my strategy, and fits my risk-taking approach, not yours. Do you know what kind of project you are working on? Should you be?"
Partial Commitments to Projects Create Unpredictable Projects - "...Partially-committed projects are not projects you can predict anything about. Yes, they have people assigned to them. Yes, they even make some progress. But how can you predict anything about the project?..."
From Esther Derby:
Specialists AND Generalists - "...if you have a project with many specialists, you end up with lots of politics as people seek ascendancy for their particular concerns. If the specialists are acting as vendors to a project team, those specialists may not be invested in the delivery goal of the project, only in delivering their part answering their concerns."
Three Myths about Teams - "...Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun."
Visibly Valuable - "...Here are 10 things you can do as a developer to make yourself more visibly valuable, which may keep you off the RIF list..."
They've also got a few books, most of which I've read, and all of which I would recommend...
How to detect bullshit - Scott Berkun: "Great teams and families help each other detect bullshit, both in others and themselves, as sometimes the real BS we need to fear is our own."
Protecting the Workgroup - Fast Company: "...in high-performing groups, the leader 'protects' the group from the larger company, whether lobbying for more resources or shielding the group from company interference."
Designing Interactions - Bill Moggridge (Recommended book.) - First sentence: "Who would choose to point, steer, and draw with a blob of plastic as big and clumsy as a bar of soap?"
Leading Ideas: Walk the Fine Line - Fast Company: "By definition, if you want to create something extraordinary you've got to leave the majority. You've got to break free from commonly accepted ideas and practices and go out on a limb. The catch, of course, is that you risk your sanity in the process. It's never easy to be a non-conformist, dissenter, or rebel. You end up walking the fine line between crazy and brilliant. But if you want to look back on your life and smile, it's necessary from time to time."
We specialize in everything - Seth Godin: "It's okay to specialize in being a generalist, of course. By that, I mean that there are many problems...where someone who can see wide and doesn't have an allegiance to a particular solution is exactly the right person to call. I rely on generalists all the time, and so do you. My point is that you never call on these people when there's a better specialist available. And in the old days, a little town could only support one generalist, so it wasn't an issue. Today, especially in high-value situations, that's just not the case. So, yes, generalize. And specialize in it!"
"...If you ask people to deliver results, you are likely to get them. If you measure or assess people on how they perform certain tasks, such as yelling at program staff, or how well people work on a task in isolation, you will get what you measure. But it won’t be what you want.
"Remember to measure what done means, not the tasks people do..."
One more time...Tell me how you measure me, and I'll tell you how I'll behave. (Goldratt)
Recent Linkage: Herding Cats -- Not enough time to do these justice with my own commentary, but here's some recent posts from Glen Alleman that I've been sitting on...
Herding Cats: Making Credible Estimates "The art of estimating the cost and schedule aspects of a project a fraught with problems. The primary issue is the belief that estimates are either credible or completely worthless. Both extremes are wrong of course. But a reality check needs to be taken, before understanding how estimates can be put to use..."
Herding Cats: Status Reports "Status reports always seem to be a thorn in the side of many project managers and managers in general. Status reports tend to be "wrong headed" in general. Here's how to fix this and get back to adding value..."
Herding Cats: Useful Project Management Quotes "Many times I'm sitting in a meeting or driving along thinking about projects I'm working on, or even better riding my bike far away from home and a thought comes to me about how to wrap up a complex concept in a simple phrase. Here are some that have come to the surface lately..."
Management of Projects
(Definitions of "management" - too short to quote. Click the link.)
If you're interested in project management but not already following Glen's Herding Cats blog, you should really give it a serious look.
Rocks Into Gold - A parable for our time from long-time blog buddy Clarke Ching.
Sopranos, Uncensored - NSFW - A little diversion featuring very bit of foul language from every episode of HBO's classic series, but not including the curses coming from the audience at the end of the final episode, when they thought their cable had gone out at the most inopportune moment possible. Someone somewhere has too much time on their hands. Surprised, though, that it's only 27 minutes long.
Rob Newbold on Agile and Critical Chain -- I'm not going to quote it. You should read the whole piece on Agile and Critical Chain from a guy who was there at the beginning of Critical Chain.
"Project managers wear many hats. We are members of teams, leaders of teams, we are followers, we are stakeholders, we are fiscal planners, we are risk managers, risk takers, planners, schedulers, mentors, quality assurance reps, writers, motivators, listeners, we are empathetic, we are sympathetic, we demonstrate common sense when others don't, we demonstrate a fair and balanced approach to problems, and lots more.... You get the idea. You can see why we are sometimes frustrated. You can see why we need to be as professional as we can all the time."
Project Monogamy, Revisted - Serial Monogamy Project Participation is an important post from Johanna Rothman. Success in projects in an organization is less about how the individual projects are managed than about how the multi-project system of shared resources are managed.
What I’m finding interesting in my work is that people who have some slack can commit to one project much more easily than people who are 100% “committed” to a project. The people who are 100% committed have no slack to provide other projects some consulting or provide future projects some thinking. The people who are only 80% committed to one project (and not committed to something else, slack is key) are more able to finish their work and accommodate the inevitable interruptions.
When people multitask, they are not committed to a project. They have no slack. They have no time to innovate. They are always behind."
Not only do resources need slack, but project promises need to me made in a way that includes "slack", allowing for those times when things don't go as planned and for those times when one project impinges on the progress of another.
The behaviors and expectations that Johanna describe allow that latter situation to happen less frequently.
Earned Budget Management - In Herding Cats: Some Serious Misunderstandings About Earned Value, Glen sets the record straight. It's about budget associated with work, not "value", unless you think of value (of the contract) earned by the delivering entity. In the agency world, a reasonable corollary is "recognized revenue".
Evidence of Critical Chain in the Wild -- One of the heartening things I've discovered during my job search is that of the two firms that I've had sufficiently successful conversations that they might be in my future, one manages their multi-project organization "the TOC way" and the other is seriously considering doing so. I knew about the first going in, the second was a pleasant surprise sprung upon me in an interview.
No Respect -- Scott Berkun has written a great piece in Why project managers get no respect, on the perceived roles of PMs - perceptions that are created and reinforced by all the bureaucratic trappings with which many PMs surround themselves with as proof of their value.
"This lack of respect creates a huge opportunity for people who open minds: their expectations of you are low. If you take the time to find out what it is that the people on the project need from you, or value from you, and make that as large a part of your job as possible, you'll get more respect than you expect. And you may find that people start referring to you as a different kind of PM - one who has changed their opinion of what PMs can do for a team - and you’ll earn not only their respect, but their trust and best work too."
This is so very much in sync with how I have tried to perform the PM role and something I've had to think about carefully for interviews in my current job search.
Project Management - the way I try to do it - is 1) about serving/leading the team (worrying about the process not to keep the team in line with it, but rather so the team doesn't have to worry about it), 2) about helping the people who do the making understand what they are making, defining (for communication purposes) the boxes, and more importantly (for modeling the effort for them), the arrows between those boxes, and 3) assuring that the promises being made are both feasible and realistic at the outset, and protected along the way (especially working with other project managers to avoid/minimize cross-project interference).
In my last four years at an interactive agency, one of the things I am most proud of is that while in the beginning, I had to horn my way into certain projects to get to know the business and its processes, in the end, teams were asking for the support of myself and other project managers in the firm. I like to think that I didn't change their opinions of project managers as Berkun talks about (because project management was not all that mature in the agency four years ago), but rather taught them by example how to rely on our project managers to help everyone do their best work building our marketing programs and web sites.
It wasn't out plans and schedules. It was our communication supporting our dedication to helping the team and the client meet their goals.
...all PPM projects have to be managed as change management initiatives. The leadership involvement and cultural change expected from stakeholders is essential for the successful completion of the project portfolio process.
This echoes conversations I've recently had with Critical Chain-savvy software providers like Realization and ProChain as well. One of the biggest stumbling blocks to successful implementations that are expected to have sustained longevity are the people who expect the software (with a little process change) to provide the solution.
It ain't just process and technology. If significant improvements are expected, it's the thinking and culture of those involved that will have to significantly change. Nothing kills benefits of a change quicker than a failure to "walk the talk" on the part of the leadership. That's a cultural change that requires careful management and some serious coaching until the desired way of thinking is automatic.
Common Sense PMBOK - In A Simple Way to Put PMBOK to Work, Glen Alleman translates the PMBOK to a set of 3 to 6 questions for each of the 8 PMBOK knowledge areas. Nicely done, in terms of keeping things as simple as possible, but not simplistic. Some of the questions might not be so easy to answer, depending on your PM maturity level, but having them in front of you should move you to developing answers for your project.
"Carry too many people on the bench, and the company is sluggish. The same as if you carry too much inventory. Carry too little, and the company can't respond to consumer demand."
If services rely on talent the way manufacturing relies on inventory, why not manage them in a similar manner, allowing demand to "pull" on an understood replenishment chain? I think I'm starting to get it.
(Also starting to like that word "talent" as a replacement for "resources".)
However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success...
...and that getting bogged down in the details too early in a project can be distracting and debilitating. When planning, it's better to work top down, with less details defined the further out in the project, since they'll probably change anyhow.
Once in the throes of the execution. you need to step back from the details every once in a while to get the big picture, the context, and an understanding of how your details fit together with others.
While the "devil's in the details," songwriter Paul Simon points out that "there are angels in the architecture."
Steve hits the nail on the head about the roles of specialists and generalists.
1. Generalists and specialists need each other... 3. Projects grow exactly because of the combination of generalists and specialists... 4. Many people are generalists and specialists at the same time...
No problem is an island. (It's a peninsula.) Every problem lies within the domain of a larger system. While specialists are needed to solve the detailed technical aspects of a problem, generalists are necessary for keeping the big picture in mind, and watching over the possible systemic implications of the specialists' solutions, or at least knowing which other specialists to check with.
Generalists are the keepers and askers of the necessary "informed dumb questions" that can be too easily overlooked and unasked when buried in the guts of a problem.
Making Parkinson's Law Work for You -- More from the book I mentioned yesterday, The 4-Hour Workweek...
If I give you a week to complete the same task, it's six days of making a mountain out of a molehill. If I give you two months, God forbid, it becomes a mental monster. The end product of the shorter deadline is almost inevitably of equal or higher quality due to greater focus.
This presents a very curious phenomenon. There are two synergistic approaches for increasing productivity that are inversions of one another:
1.) Limit tasks to the important to shorten work time. (80/20) 2.) Shorten work time to limit tasks to the important. (Parkinson's Law).
The best solution is to use both together: Identify the few critical tasks that contribute most to income and schedule them with very short and clear deadlines.
Of course this assumes you are capable of fooling yourself into honoring self-imposed short deadlines - kind of like setting your clocks fast to avoid being late.
Agile Task/Process Mgmt vs Project Management -- Long time blog correspondent Glen Alleman has recently acknowledged an understanding of agile software development that's "dawning on him"...
"In a recent exchange on Agile Project Management, it has finally dawned on me that when the agile software development advocates speak of project management they are not actually speaking of project management. They are speaking of managing software development..."[Be sure to read the rest...]
Yup. Pretty much a similar conclusion I came to back in 2003, when I had time and energy to ponder such things (as well as a vested interest in promoting Critical Chain Project Management and its potential as a PM overlay for agile efforts).
"While on the subject, I've been recently trying to wrap my head around the various flavors of agile software development, and what they describe as "agile Project Management" (which has more of a sound of "task" or "process management" to my ears). There's been an excellent discussion of this in the Newgrange PM discussion list, which starts in the YahooGroups archive here."
"One of the things I think I'm seeing in Davids' book is a distinction between "agile" work methodologies and practices and project management that can wrap around them to make promises...a distinction that I've come to myself. The things that fall into the agile approach are about work/task management for a certain type of work, and don't really meaningfully address the promise-making and promise-keeping aspects inherent to project management."
Of course this assumes agreement that a major function of project management is about making promises, and understanding the health of and/or modification to those promises in an attempt to keep them.
"Agile Software Development" is a set of processes governing how software development tasks are organized and performed. But software development is only part of a project, even if it is a software development project.
Along these lines, sometimes the source of calm is knowing that "strategic quitting", like that discussed in The Dip, from Seth Godin. Being able to discern the difference between a "dip" and a "dead end", and act appropriately, can be a source of calm.
For example, from my project of preparing for a comfortable retirement, the stock market this year has been kind to those that have "bought the dips" on the way up, although, on the other hand, "bailing out" with profits in hand can be not only prudent, but profitable as well.
CLIENT: I'm about to talk to the pharma client, I need a computer graphics budget for an interactive CD-ROM.
ME: Great, email me the project details, how many screens, client deadlines, etc.
CLIENT: Well, can't you just give me a ballpark figure?
ME: A ballpark figure? But, I don't know any of specs, nor any of the client info. Please send me what you have, I'll look over it this weekend and I'll have something for you first thing Monday morning.
CLIENT: Well, we need to send them something today, by 4:30PM. Can't you just estimate it?
The Most Important Trait? -- According to a survey at CIO Blogs...
What's wrong with this picture?
That item leading the survey with 38% of respondents - the ability to juggle multiple priorities - is pathetic. It's management's responsibility to determine the priorities, either by edict or, preferably, by some systematic process, and to provide processes to minimize re-prioritization as much as possible. If left up the the folks doing the work, either juggling and multi-tasking will occur, resulting in dropped balls and unnecessarily extended delivery dates, or those folks doing the work with choose a priority, which may not coincide with the priority best for the firm.
I've got to believe that this survey was put together with tongue firmly in cheek. I want to believe that this survey was put together with tongue firmly in cheek. Please tell me they (including those who responded) were kidding. Please.
Critical Chain Case Study - Pharma -- Over at CCPM software provider Realization's site is a case study on the implementation of Critical Chain-based multi-project management in a pharmaceutical environment...
Implementing the new approach has boosted performance of clinical supply operations:
Lead times were reduced from 8-12 weeks to typically 3 weeks, a reduction of about 70%.This is substantially lower than the industry average of around 6 weeks.
Due-date delivery was over 90% (for five consecutive months).
Without additional resources, about 50 studies were now packaged every month, a throughput increase of 150%.
Besides the quantitative improvements, there are also qualitative benefits felt by project participants. Managers feel in control of operations and now make decisions proactively to stop problems before they become problems. Another benefit seen is that as the rank and file do not need to multitasking (because they get clear task-level priorities), they can focus on delivering highest quality output. This is extremely important in clinical trials, as any quality problems can lead to the whole clinical trial results being rejected by FDA.
Rizzo on Speed and Profitability -- This looks like excellent news. One of my former co-workers and friend from the TOC community of practice, a thinker/writer/teacher/consultant well worth knowing (I wish he would start blogging), Tony Rizzo of The Product Development Institute and Spherical Angle, seems to be writing a book. At least there's a series of pages on his PDI website that refer to chapters 1 through 4 (as well as an empty link for chapter 5) of something called Speed and Profitability with the Six Sigma Enterprise. These chapters touch on similar notions of multi-project management that you've been reading here, but with Tony's unique ability to draw pictures in the mind. For example...
For a moment, think of each of your projects as a person. Imagine that you have fifty such people in one room of your facility, and you need to get all fifty into the adjacent room as fast as possible. There is one door connecting the two rooms. Now, imagine that each of these people is rewarded (or punished) on the basis of how fast he/she can make it into the next room. The ones who make it through quickly can expect to receive a reasonable reward. The ones who make it through a bit late get only their base salaries. The ones who make it through very late can expect to be encouraged to find employment elsewhere. Go ahead. Give the order to move, if you dare.
Commonsense tells us that a few of your fifty people will make it through the door immediately, until the crowd arrives. Then, some of them will try to make it through sideways. A few others may become creative and try to take the low route, only to cause others to trip and stumble. Soon, you'll see a mountain of bodies, many of which make it through the door very late, and perhaps with injuries. You may also see a few people standing back, waiting for the mob to clear.
Now, imagine that every few minutes you give the order to 20 or 30 more people to go through, while the mob continues to block the door. It's clear that nearly all will make it through very late. Many of these will suffer severe injuries. The ones who decide to stand back and wait for the mob to clear never go through, because the mob never clears.
This is probably a close description of the way your projects compete with each other, for shared resources. In our little scenario, the door is a shared resource. In reality, the shared resource may be a group of systems engineers or software developers or electrical engineers...
Nice visualization. Tony goes on in Chapter One to talk about unsynchronized multi-project environments and the resulting multi-tasking sickness that he refers to as the "dilution solution". I'll probably be getting deeper into the subsequent chapters as time goes on, but don't let that stop you from digging into Tony's stuff yourself. Now.
...
View Frank Patrick's profile
