Feb 08 2010
∞
Jan 12 2010
∞
PapercutPM Takes it Off (omg hawt)
Jason Martin wrote an excellent article about a debate I had with MyPMExpert on Twitter (moderated by TheGreenPM). In it I was contending that the further the PM is away from his or her comfort zone in terms of subject matter domain, the greater the risk to both the project and the PM.
After reading it, I started thinking about the article, and why I take the position I do. I thought I’d share a little bit.
I’ve run all kinds of projects through the years from simple to mind-scramblingly complex. I came from the trading floor where not only did we have some very hairy projects involving legacy systems integration with enterprise-wide applications, but we had to do it with some horrible, horrible stakeholders. Traders have gotten a lot better over the years of humbling market crashes, but the stereotype of trader as money-making / money-spending arrogant monster hasn’t gone away entirely.
Through it all I had a great rapport with my teams, and my stakeholders and I all had a common understanding. Don’t piss in my cornflakes, and I won’t piss in yours. And beers are on me after. I became about as arrogant as my clients—there was nothing I couldn’t do.
Then one day I joined a consulting firm and was put on a chequing program. I knew nothing about chequing. But how hard can it be, right?
Well, it turns out, plenty. I wasn’t the program manager…I was given one piece of the program to manage, the front loading portion called “cheque capture”. I had to plan out a series of nine different releases to span four years, many of which would run concurrently. In the first week I rallied the troops, and hammered out a gorgeous, detailed project plan of about 1000 lines, inputs and outputs to other plans, and anticipated risks (all written in sexy colours). I set everything up and away we went.
Then the problems started happening. Mechanical failures. Sorting problems. Rejects. People put gum and staples on their cheques which buggered up the hardware. Consumers wrote cheques in pink marker that the scanners couldn’t read…on mylar cheques that reflected glare back at the camera. Sorters were configured perfectly and still wouldn’t work.
Day after day, the issues compounded; issues my people didn’t anticipate, and some issues it turned out they did anticipate but I didn’t ask the right questions (and they didn’t volunteer). This was a multi-vendor program, so some vendors were more than happy to “accidentally withhold” information if it meant they could take revenue away from their competition (“oh, gee, that’s too bad they didn’t catch it…we certainly would have if we’d only been there”).
And everything we did still had to integrate with the other teams’ work. They were facing similar issues. We raised an endless string of change requests because if our team slid because of the problems we were facing, the other teams who depended on us had to slide. And vice versa.
In program review meetings, we watched expenditures balloon as we flew more experts in to deal with issues. Because of the parallel nature of the program (and the delays), skilled resources got spread too thin, further slowing work. The program manager’s response was to add more layers of management. Functional meetings bloomed out of control because by this time there were hundreds of people working on this thing…I couldn’t get a parking space that didn’t involve at least a two block walk, and more than half the resources were sharing desks across two buildings.
When my doctor refused to give me any more Xanax I knew it was time to reassess things. LOL I committed to stay through the first release, and the second release until integration testing, at which point they’d need to replace me. We kept things moving, I met my deliverables and went on my way. Before I did, I advocated strongly they find someone with chequing experience.
Why was I so stressed? It was a project, and I’m a project manager (and a damn good one). But I was on very insecure footing, in a domain I had to learn on the fly. As project managers, our job is to take teams off into the unknown, define the destination, and plot the journey. If we have a reasonable sense of the journey, we can be confident that we can face the challenges that lie ahead. That will inspire our teams and instill confidence in our stakeholders. When we take up the mantle of responsibility on a job where we’re doubly blind, the unseen risks proliferate. It wears you down.
CAN a project manager guide any project to the finish line using the tools as their disposal? I would say yes, I believe so. There are processes for changing scope, and managing expectations, thereby eliminating budget or schedule concerns.
SHOULD a project manager try to take a project they know nothing about to the finish line? I’ll let you decide that one, but I know my position.
+
∞
In the forums I’ve been participating on recently, I’ve seen an awful lot of questions regarding the above terms. It seems there’s a lot of ambiguity around these points. Today I’m going to throw my two cents out regarding the differences. Ultimately, I believe they’re different steps along the same continuum, which is probably why there’s so much splitting of hairs regarding which is which.
On the surface, the response is simple:
- An assumption is anything you “assume” to be true.
- A risk is anything that could go wrong.
- An issue is anything that has gone wrong.
However, I just finished having a 30 minute argument with my partner while discussing this post (and I’m likely sleeping on the couch tonight). It indicated to me that on the surface the definition of these three items seems very simple, but the relationship between the three has a fair bit of complexity beneath the surface.
Assumptions
A lot of people don’t like these, and will always quote Samuel L. Jackson from The Long Kiss Goodnight (I love that movie) by saying, “When you make an assumption, you make an ass out of you and mption”. However, the reality is, nobody has all the answers. If they did, there would be no need for us project manager schmoes at all because everybody would automatically know what everyone else was doing. We’d be out of work!
When you go into a project, there are certain points you have to accept as given to be able to make certain decisions, even without all the facts. It’s true, those assumptions may later prove to be false, but if you’re too afraid to make them, you’ll be paralyzed. The effective manager picks up a stake, drives it into the middle of the boardroom table saying, “we’re going to assume X until it looks like we’ll be proven otherwise”, and everyone else at the table cowers away from the shining beacon of holy light that is the PM. (Okay well that never happens to me…I’m having a good day when my shirt tail isn’t sticking out of my fly, but you get the idea.)
As to what an assumption is, it’s any unsupported statement that people believe to be true. Period. Assumptions have no good or bad, they just are.
Risks
Like assumptions, risks are theoretical. They haven’t happened. However, risks have very specific properties that should be noted. First of all, a risk has consequences attached to it. These are usually phrased as “something bad”. If you’re going to consider “something bad”, then you need to think of how likely that bad thing is to happen, and how bad it would be for you if it did happen (impact).
Because I’ll be criticized later by all the smarter-than-me folks with PMPs and stuff, I should point out that the opposite of a risk is an opportunity. Opportunities have the same properties as risks, but you can replace “something bad” with “something good”. Just like risks, opportunities need to be called out for what they are if you’re to take advantage of them, and plans put in place to make the most of them.
From a definition perspective, a risk is something bad you think could happen, measured by likelihood and impact.
But a risk is also the antithesis (not the opposite) of an assumption. If you make an assumption that something is safe, there is always a risk that it is not safe. That’s because the underlying assumption, by definition, is unsupported by facts. Here’s where we start to run into confusion.
If you proceed with a course of action knowing that a risk exists, you are making an assumption that it’s safe enough to proceed anyway. Whether you call the assumption out for what it is doesn’t change the fact that you made it. As stated above, assumptions are necessary to make decisions; risks need to be identified to protect yourself.
Issues
Issues are not theoretical. They’re full-on happening and in progress. Once they’ve cropped up, issues have a tendency to continue to get worse until they’re dealt with (snowball), so your approach to them needs to be completely different from managing risk.
In an ideal world, you would have worked out your approach to issues beforehand during risk analysis; in practice, issues come out of the woodwork to bite you in the ass.
By definition, an issue is a bad thing that has happened. It needs to be dealt with. Again, here’s where the confusion lies…
If you identified the issue as the consequence of a risk, then good for you, you have a strategy to deal with the issue and get rid of it quickly. However, if you didn’t identify the issue as a risk consequence, that doesn’t change the fact that the risk existed, whether you thought about it or not.
From a functional perspective, you need to identify assumptions and risks at the onset of the project. As the project progresses, you need to continue to challenge your assumptions and risks. Issues, on the other hand, because they’ve graduated to actual, need to be handled tactically. That means, get people working on a resolution as quickly as you can.
Ultimately, the reason (as I see it) that there is confusion among the three terms, is because they are all directly related to one another, but that relationship is often only recognized in hindsight. It would be super great to have a time machine to go back and prevent problems, but for us humans, all we can hope to do is the best we can.
Jan 05 2010
∞
More PM soft skills, please!
People who have been following me know that my position on being a PM is simple. A project manager does what it takes to get a job done. A lot of times that means talking people off ledges, holding Kleenexes out, buying beers and staring at the wall mindlessly blinking when nobody’s looking. I keep a little bottle of Xanax in the back of my desk drawer (they’re for me).
I always called it the “Forrest Gump” aspect of project management. Sometimes things happen and you just have to deal…often that means showing a little vulnerability to win people back to the project. This shouldn’t be excessive (i.e., resources hold the PM hostage), but projects can get tough and when they do, people you’d expect to hold up against a typhoon suddenly turn to jelly.
If the PM takes a pure task management approach, but ignores the human side of the work, he may be justified in that “he did what the the methodology instructed”. But if the result is, a key resource throws his hands up in the air from stress and walks away, the project now has a huge hole. For good or bad, what has been accomplished?
For all the resources on PM best practices, methodologies and procedures, I find folks are pretty quiet about those soft skills that a PM needs, probably more than anything else, to keep projects moving along.
I’m on Twitter @PapercutPM. I’d like to hear your 140 character stories about how you hold your teams together!
Dec 22 2009
∞
One more time. The difference between portfolios, programs and projects.
I’ve been surprised to find that there’s still much ambiguity about the difference between the 3P’s of Projectland. Given the complexity out there of different organizations and how no two environments are ever alike, I probably shouldn’t be surprised. I’ve noticed over the years that most companies approach organization by throwing all their work up in the air and drawing circles around groups of whatever lands on the floor with crime scene chalk.
However, to help clear things up, I made the above diagram. Take, use, print, whatever. Because companies all have their own way of doing things, this diagram will never be a one-size-fits-all. But hopefully it’s a reasonable guideline to help give your work some structure.
The TV show model is the easiest for most folks to get their head around. The WB (I believe) was the network to produce my favourite TV show ever. They had to worry about all of their shows, funding, and strategic planning. In addition to their shows, they would have had loose projects that didn’t fit into any particular program.
My favourite show ever (Buffy) had loose time boundaries (it gets cancelled when it gets cancelled), and fairly defined high level scope boundaries. Within their story arcs, they have to worry about choosing strategic plots (development over time, which Joss Whedon is a MASTER at), or tactical plots (whoops we wrote ourselves into a corner OR crap we have a blank spot in the schedule and nothing to fill it with).
And of course each episode can be considered its own project, with very clear time, money and scope boundaries (has to fit within the time slot, has to be ready to air, has to fit within existing and current story arcs, etc.). The specific skills required to produce one episode are clear and the processes required for execution are also clear prior to the onset of execution. (I know, I know, Dark Willow was more than one episode but it was AWESOME)
While not every business makes TV shows, the same organization can still apply. Insurance companies print policies to mail to policyholders. The printing of different kinds of policies could be considered one program. The development of one particular game title could be considered a program (if the game title is large enough, it may even have subprograms before it gets into specific projects).
There’s lots of different ways to cut it within the basic overall structure, but keeping the above attributes and challenges of each group in mind should help give your work a bit of definition.
Dec 21 2009
∞
In the spirit of the season, @PapercutPM is pleased to provide you this short presentation. For most of us, we’re born, we live and we die…to create a legacy, you need to try harder.
Understanding and being understood is the true currency of success.
+
∞
(via juliasegal)
Dec 19 2009
∞
Dec 18 2009
∞
It’s important for all project resources to have a tool that lets them see what other team members think of them. Make no mistake, whatever role you play on your project, everyone is looking at you a different way.
