|
|
You’ll enjoy this blog entry from Project Connections:
http://blog.projectconnections.com/project_practitioners/2010/01/managing-the-common-coldas-a-project.html
The author, Margaret de Haan, suffering from a severe head cold, writes out a project plan, complete with tasks (coughing, sneezing, TV watching, sleeping, taking, meds, etc.), schedule, Budget ($94 cold!!), Risks (flu instead of cold) with associated costs (more doctor visits and meds), etc.
It’s good laugh, but it’s also a good reminder of insights you can glean by writing down the basics of a project plan for just about anything. Did you ever expect your cold cost you $100?!
Enjoy!
There’s been an interesting debate in the PM space for a little while. As Agile development practices continue to expand, there’s a natural tension as both the PM camp and the Agile camp try to figure out how mesh their methodologies. The debate centers around core differences in the traditional PM approaches and the new Agile approaches to managing a software development project. (There’s even the more pedantic discussion about what is a “methodology” and what we can call a “methodology,” but that part isn’t interesting to me.)
The debate’s been going on long enough now that the community is beginning to come to some consensus (just beginning to, mind you). The most promising outcome I’m seeing so far is a refocusing on the results that matter. In the January 2010 issue of “PM Network,” Jesse Fewell, CST, PMP (@jessefewell) writes on this topic (“Why Methodology Doesn’t Matter,” p. 27; view it at PMI.org here or on his blog here). I like his conclusion:
The most effective approach is tailoring established best practices to fit the unique traits of a given organization and the specific project at hand.
That perspective is helpful in project management, whether or not you’re in a methodology debate. It is also a very important perspective for those of us in “Cottage PM” environments where there is perhaps no PM methodology at all! We’re feeling our way along, learning PM principles, or working to apply those principles and practices in environments where they’re not used yet. We get the raised eyebrows. We get the “don’t bother me with that garbage” responses.
Focus on results and adapt
Whether you’re doing Cottage PM or not, you need focus on results. More specifically, I think, you need focus on value creation. In Cottage PM, as you try to introduce new methodologies, don’t let those methodologies become and end to themselves; they are a means to an end, the means to create some value for the organization. Adjust your PM practice to fit your organization and your project to ensure that value creation, not just to have a pretty WBS because you think it’s supposed to exist.
Jesse offers 3 steps to help you tailor your approach. It’s a good list for Cottage PM practitioners, too. Here they are:
1. Start with what’s easiest.
If your organization actually has a standard approach to projects, work within that approach, improving it as needed. If they don’t figure out what processes and tools you have that would best fit. If your organization doesn’t know what a WBS is, perhaps you don’t call it a WBS. As a PM, you should still be building a WBS, and you should be finding ways to do that collaboratively with the project team. To help your both tailor that approach and communicate it effectively, focus on the “payoff,” the benefits that the organization will realize by doing that work. You still need a schedule, but again, tailor that to what the organization can consume and focus on payoff.
2. Deliver early, deliver often.
Saving up all the deliverables for the very end reinforces stakeholder nervousness; it makes it harder for the PM to measure progress; and it makes it harder for a project team to maintain motivation. A steady stream of deliverables makes it easy to demonstrate steady progress. If you’ve introduced new tools, like WBS or risk management, then you’ve introduced a new variable for the organization that’s risky and needs to be proven. Steady delivery will help demonstrate the value of these tools.
3. Inspect and adapt.
Set a regular review process that will let you and the project team make judgments and adjustments to project methodology and project realities. For example, as I wrote recently, I discovered that one of my project team members wasn’t interpreting the WBS properly and needed some coaching on how to consume that tool. Regular reviews help expose those issues earlier than later. Regular reviews also help you manage the project itself better, methodology aside.
You can successfully introduce these practices in any organization, and if you do, you’re projects will be more successful more often, and where they’re not successful, you’ll probably know that sooner than later and can help the organization minimize the negative impact of “failure.”
I read an interesting tidbit recently: “Parsing” by Clay Johnson (@cjoh), included in Seth Godin’s eBook: What Matters Now. Here’s an excerpt of the tidbit:
How many times have you paid your taxes? Ever get a receipt back telling you what you bought? You’re paying for something, right? Why is everybody arguing about taxes and deficits when they don’t know how their money is being spent?
Imagine if we organized oround meaningful data instead of vapid rhetoric. What if you could see how much you psent on your commute to work this year, or defending your country, or keeping your neighbor healthy?
Most of the data exists and what doesn’t we need to demand. The answer to a healthy democracy lies not in rhetoric, but in our data.
The same logic reaily applies to our projects.
One of the PMBOK’s process groups is Monitoring and Control. Functionally speaking, I think that Monitoring and Control is very closely tied to Managing Communication (PMBOK Knowledge Area). I tend to use the same tools for both.
What your stakeholder needs
Your stakeholder’s needs are reflected in the quote above: “Ever get a receipt back telling you what you bought?” That’s what your Stakeholders are looking for all the way through the project and at project closure: evidence and proof of what they’ve bought. The answer to providing that consistently and clearly is also reflected in teh quote above: “The answer … lies not in rhetoric, but in our data.”
Planning for project control and communication: data
Where is that project data?
That’s up to you. Look at your current projects. Do you know right where that data is: current status, work completed, deliverables, demos, budget info, forecast, etc.? No? Then perhaps you need to plan for the ability to produce and manage that data. Start in your WBS. So many PM’s advise including Project Management deliverables in your WBS. Deliverables like these. You need to plan for exactly what reports are going to be needed to prove what’s been bought, and you need to know where that data is coming from.
If you don’t, then your project status reports and communication will depend on gut checks, guesses, or the latest status you could drag out of your developer at the water cooler that morning, or via text message while you and he both were at different kids’ soccer games the night before.
Project control requires much of the same data. If you can’t communicate these data bits reliably, you’re probably not in control of your project at all. You can’t have control if you have no plan. The plan tells you where you’re supposed to be. If you don’t know where you’re supposed to be, you can’t say whether or not you’re on schedule, on budget, etc. If you can know those answers, then you can probably communicate them easily enough.
In smaller projects (Cottage PM), you can do this really simply. I like the WBS as a core tool. I also like the One Page Project Manager tool by Clark Campbell. It’s a great planning and communication tool for your whole project, all on one page, and easy to update and manage. Maybe I’ll write some more about that tool later.
OK, that title sounds more noble than I’ll be writing. See, I just caught a flu bug. Not very severe, and hopefully it won’t become severe. But it’s been flirting with me for 4 days now, and the fever finally began today, just when I thought I was getting better. But this post isn’t about me whining about flu.
As I signed off from work at noon, I realized that a few of my key initiatives will continue without me for a few days just fine. Others may suffer a bit. Not all of them are defined as “projects;” most are operational activities. But technically, I suppose more of them should be treated as small projects on the operational team — they’re new, they’re unique, and they’d better have an end date, or news won’t be good. 
Alas, some of the projects have good plans and expectations. Others, not so much.
Realization #1: Good project planning mitigates risk
Good project planning itself provides a certain risk mitigation. What happens to your project if the PM gets sick and has to disengage? That may be challenging enough on a huge project with solid project plans and a few assistant PMs around. But what about us in the Cottage PM space? We’re functioning where there is little formal project knowledge, virtually no project formalities. We have talented people, but even talented people need solid direction. What if you had to cut and run for illness or some other reason? Will the work continue?
One way to help make sure that your talented team can continue is to have a solid WBS and schedule. Then, if you as PM must disengage for a week or so with illness, they at least have a chance to know what to do next. If all that direction is buried in email in boxes and scattered across meeting notes, it’s a lot harder for someone else to continue on the path you intend.
Realization #2: The team has to know how to use the project plan
This week, I also realized that even creating a WBS and schedule with one’s team is not quite enough. The team has to know how to use it!
I posted for you last week a WBS that I’d created for a current effort. This week, I realized that one of the team members — one of those really talented, get-it-done-when-no-one-else-can people — wasn’t interpreting the WBS the same way I was. It wasn’t a dictionary or writing problem; it was a structural problem. He didn’t realize that the WBS and its dictionary were so strictly hierarchical, that all the sub items make up the higher level item, or that a higher level item isn’t “done” until all of its sub-items are “done.” Despite a hierarchical organization of the WBS and dictionary, he was reading it like a flat file. That didn’t create any major problems, no, but it did mean that he and I weren’t quite speaking the same language and status update details didn’t match facts.
Conclusion: Even creating a WBS and schedule with the team may not be enough, because they may not understand all the assumptions of how the documentation is organized, while they do understand all the pieces. One must also train the team on using the project plan.
Some of that can happen organically by using the WBS and Schedule, for example, in status meetings and other communication. In fact, that’s how we discovered this disconnect on our team this week. My team member had taken that documentation to heart, recognized clearly the items assigned to him, and was providing me status on each one. So it wasn’t a complete failure. Over time, we’ll complete that understanding. The next project will go even more smoothly.
Cottage PM Considerations
In Cottage PM, without formal PM knowledge and practices, the PM needs not only to figure out how to scale and use PM tools effectively in his organization, he must also actively drive that learning process for project team members, lest much of the value of the PM processes be lost and counted only as so much admin overhead.
And now I’m going back to bed.
I thought the little project was simple enough not to bother with a WBS. It was straightforward work that my team was accustomed to doing. This week I reconsidered that stance and built a WBS, and boy am I glad I did.
The Project
The project is to configure the CRM for a unique extended support offering. The launch is in March, roughly 60 days away. My team sets up support program configuration in the CRM all the time. We did initial feasibility conversations and even took basic configuration decisions in November. Then we put it on the shelf until after the holidays. We figured it was pretty straightforward stuff that would fall into normal operations.The work involves 3 primary project team members: the sponsor (program manager), myself (team manager & PM), and the tech (system config). We each work with several other people as needed to do our work, but we own the work outright.
We’re late January now and we pulled it down from the shelf to begin finalizing configuration, validating some November assumptions, etc. As we held those discussions, I began to feel like there were lots of details, assumptions, and decisions that needed more attention, more tracking, more review, and more validation, before we went too far down the path. I began to realize that this wasn’t as “normal operations” as I’d thought and I was really in “unique” project land. It was time for a WBS.
Project WBS
 So, I took my hand to creating the WBS. My stress level began to drop as soon as I began. You know, loose ends being gathered up and such. It’s a beautiful thing! The tech and I reviewed it, then the sponsor and I reviewed it today. It grew and changed each time, which is both expected and desired. It’s fairly complete now.
And we all had the same response.
Wow.
Big.
More than we thought.
(At least we are having that response now and not 60 days from now. We have plenty of time still.)
Since doing my last formal WBS, I’d studied Josh Nankivel’s WBS Coach package. I used a lot of his ideas to create a cleaner and more complete WBS than I’ve usually done. And I decided to do a WBS dictionary this time. I don’t usually do that, but Josh won me over to his way of thinking. When I was done, I liked the additional clarity that the WBS Dictionary provided.
Here are my WBS and WBS Dictionary:
 WBS Example - Click to see full-size image |
 WBS Dictionary Example - Click to see full-size image |
Some Things To Notice
Taking from Josh’s notes and some other project management thought, here are some things to notice in my WBS.
- I’m a “Working PM”: In other words, I own some project deliverables. I’m both PM and Project Team Member. It is often written in PM literature that there are important risks with being a “Working PM.” Those risks center around the loss of PM focus, and they’re real risks. But in small project environments that like those I write about, it’s usually unavoidable. You just have to recognize the risks and defend that time and focus on PM activities while still lending your expertise to the project deliverables. That expertise is part of your unique value to the project. Don’t apologize for it, but be vigilant about your PM duties and the time it takes to do them properly.
- Deliverables-oriented; no tasks: Josh is adamant about having a deliverables-oriented WBS. I tend to agree with him. Every time I’ve tried to include tasks or verb language in my WBS, I lose control of it. Not all PM researchers and experts agree with this stance, but I find it much more functional, much clearer. And clarity is good.
- Support Activities: Despite knowing better, at least academically, I’ve never included included PM activities in my past WBS’s. I included some this time. I like having it there. Not having done it before, I was unsure how to include these activities. I leveraged Josh’s example WBS and WBS Dictionary in the WBS Coach package for guidance. I slimmed it down to the tools I intend to use for the size of project I’m doing.
- WBS Dictionary includes owners: It’s not a typical part of the WBS Dictionary, but at this stage of planning, it made sense to me to include that here. I may extend this further in later planning to combine RACI info, etc., in this same file. When I build the schedule, I may use OpenProj, an opensource MS Project type of software, and I may move assignment info to that tool then. This kind of flexibility is fair game, in my opinion. Tweak the tools to match your needs. Simplify wherever possible.
- “Uneven” decomposition: All parts of the WBS are not decomposed to the same degree of detail. Josh advocates that approach, and I support it avidly. In my opinion, decomposition needs to accomplish 2 things: It’s detailed enough for me to control as PM, and detailed enough for me to us the WBS to communicate effectively with Stakeholders. If I can do those two things, then the WBS is detailed enough.
The WBS Payoff
The WBS has already begun serving its purpose this week. It’s given us a more defined and complete sense of all the work that is needed. We identified some things we’d not thought of at all yet. We’ve already reached out to the groups that we need to train to get on their calendars, even before defining the training material. We’ve validated some assumptions and corrected and completed some configuration. We’ve even been able to accomplish some early testing of some areas we were concerned about. We have a lot fewer questions marks on Friday night than we had Monday, and that’s a direct result of collaboratively building a project WBS.
Sharing the WBS
We’re a small group, but I still hate passing various versions of files in email. It’s a very sloppy, unenlightened work process. File sharing, info sharing — things need to be referenceable so that users always can trust that they’re using the latest version.
So, I created a new file folder in my team’s workspace in Novell Teaming. There, I’ve uploaded the 2 sources files. Because not everyone uses XMind, the application for my graphical WBS, I upload the same PNG file I provided you here. (OK, the one I provided you here is “sanitized” and made generic. My real one has actual product names, function titles, etc.) I’ve also uploaded a draft of the FAQ. The FAQ file name begins with it’s WBS number (“WBS 2.2.1 – FAQ”) to allow for traceability, another benefit of WBS and something that Josh discusses in WBS Coach.
Feedback
I would certainly be interested in your feedback on the WBS example that I’ve posted here. Analyze it. Rip it apart. But remember that WBS is a highly subjective exercise. Still, I’m sure I could learn from your experiences, too. To give feedback, post a comment below.
——————–
Do you need help building an effective WBS? I highly recommend the package, WBS Coach, from Josh Nankivel. I use it and I believe in it enough that I’m an affiliate for the package, so if you buy the package, I’ll get a little Pepsi money.
Earlier this month, PMHut.com posted an article, “So What’s Your Project Charter.” It caught my eye. As I hope you’ve noticed, I’ve been considering the various tools and processes that PMs can use on projects and trying to determine which are most relevant to our environment, Cottage PM (see About Cottage PM on the left nav bar).
And I fully intended to suggest that the formality of project charters is usually not needed for Cottage PM environments. I tend to shun formalities in general in my environment; they’re often quickly interpreted as process overhead with little value, and once that conclusion is made, it’s hard to overcome.
But then a colleague of mine latched onto the project charter as a solution to a huge new project problem he’s facing. I had my doubts, but today began to see some fruits of his approach, so my anti-charter stance is softening. In fact, I’m beginning to think that some form of charter is probably essential to Cottage PM success.
What’s a Project Charter?
Well, for a really good write-up, see PM Hut’s article here: http://www.pmhut.com/so-whats-your-project-charter. It’s worth the read.
PM Hut provides this short definition of a Project Charter:
…a formal agreement between the creators and consumers of project deliverables that establishes the purpose, boundaries, directions, limitations and participants of a project.
The Charter is the first run at formally defining the project. Expanding on this quick definition, PM Hut offers a few more ideas on content. The following are those that my colleague is using to define his project.
- Project Goals
- Project Scope (boundaries)
- Project Objectives
- Project Approach
Project Charters in Cottage PM
So, why am I shifting my stance on project charters in Cottage PM? Maybe we’re not building rocket ships, but our projects carry significant impact and investment and risk for our organizations. For all projects, small and large, clarity of expectations and direction are essential to producing the right output and to creating value for the enterprise.
In Cottage PM, we work where there is little formal knowledge or formal practice around projects. We work with really talented, creative people who know how to get things done. Really talented people get lots of ideas. Lots of different ideas. That’s both a boon and a bane to the PM. Lots of ideas are good for finding solutions. But at some point you have to reign that all in and align it to a single project vision.
The Project Charter is perhaps the first tool the PM can use to begin to align all those stated and unstated expectations; the first step to being able to paint a picture, to create a vision that everyone can get behind. It’s also a more formal way to validate one’s own understanding of what’s intended.
You need that just as much in Cottage PM as in larger projects. We could argue that in the absence for project formalities, you need this early definition even more than others may.
How To Use A Project Charter
The answer to how to use a project charter depends on your organizational norms and expectations. In my case, we’re getting away with using the word “Charter” — more on that below. But the charter, like any other project process or tool, should not be created and sent out as a notification. Do that, and you might as well not bother. Instead, you can either create it collaboratively with your sponsor and key stakeholders, or you can distill your own understandings into a charter, then meet with them to present it, to discuss it, and to adjust it.
For example, today my colleague introduced this idea during a staff meeting with the VP. On the agenda was a quick update about this project. As part of the update, he indicated that he was drafting a charter and would be meeting with the VP soon on that. He briefly define the charter in non-threatening language. He even shared some key points of the charter already so that it didn’t appear that he hadn’t done anything on it or that he was saving it all for later. Very open communication, but also setting a stage for more formal, more complete understanding. Now the VP has both an update and a plan for further definition. And he’s not surprised or confused by a new process. Score one for the project manager!
I Still Hate the Term “Project Charter.”
Typical teaching about Project Charter centers both on this definition value and on the idea of “authorization.” This angle of authorization may not be so meaningful in Cottage PM. Often, the PM is also the functional manager and has natural ownership over the project. Declaring some separate authority seems redundant and can lead to that perception of meaningless process overhead. However, if you work in an environment where declaration of authority is needed, then by all means, leverage the Charter for that, too.
If we remove that idea of “Authority” from the Charter, then the term “Charter” itself seems empty to me. I dislike the term. It says to me: “You’re trying to process me; we’ve already talked about this; quit forcing me down a PMBOK path and just go do what I need!”
If you face that perception risk, too, then change the name if you need to. Label it something meaningful for your environment. Or, if the term “Project Charter” is simply unknown, you may do better to simply define in meaningful terms and move on. Just don’t feel trapped by the label. I bristled at the label for a long time, and am now realizing that I rejected the value of the tool because its name and its focus on authority. All the while, I was fighting problems created by a lack of early formal project definition.
So, I stand converted to charters, though perhaps by another name.
I have hanging outside my office the overview poster that came with my PMBOK4. The poster shows a rough flow chart of all the PMBOK’s project management processes. It also shows the macro-flow between Planning, Monitoring & Controlling, and Executing. A decent flow chart. Wish I could find a soft copy of it.
One of our young developers walked by today. He helps me out when I have more technical linux questions. He saw the chart and asked some questions. The crux of the questions really came down to this:
“Out of that whole project flow, where do I fit?”
The answer, for a developer who spends all his time developing on projects, was at first discouraging. All his stuff, all his work, fit only in that box at the very center of the chart: Executing. And not just within the set of Executing processes, mind you. Pretty much just in the single process of Executing.
We chatted about it. It was a good chance for me both to reassure him about his place on the chart, and expand his understanding of what it takes, of everything else that has to happen so that he can be successful developing on the projects.
Here were the key points we discussed.
Project Planning
On the chart, planning is the biggest process group. It can be an “ah-ha” for a developer to begin to glimpse all that has to happen before he starts work, just so that he knows what the heck he’s supposed to do.
I also tied in his experiences having to redo work as requirements shifted, or as we discovered misunderstood requirements. He, like many, has had the unfortunate experience of demoing the first half of your work only to hear, “But, I thought it was supposed to do [insert new, surprise requirement].”
Planning helps to avoid that.
But that leads to the next principle: “Plan to replan.” It’s gonna happen. Expect it. Plan for it.But if you didn’t have a good plan in place, you can’t judge impact, downstream changes, etc., nearly as effectively.
And that leads to the next topic.
Project Control
In projects, “control” refers primarily to knowing where you are on your plan, spotting variance, and handling that variance.
Principle: “If you don’t have a plan, you can’t know where you are on the plan. If you don’t know where you’re supposed to be, you can’t judge variance.”
Well, you can guess. And if you’re really good at what you do, you’ll even guess right a lot of the time. That might even be more true for us in talented Cottage PM organizations — smaller project teams, smaller projects, even though they have huge impact. But it’s not necessarily true for us, either.
It goes further, too.
If you don’t know where you’re supposed to be, you can’t report your progress — at least not with any reliability — to stakeholders and sponsers.
Wrap Up
Finally, was able to point out the key planning process outputs that he uses: WBS & Schedule. The PM we have working on his team is pretty darn good, so he knows these tools well. I reassured him that from the project manager’s view, all the developer’s work might be in that one box, but in that box are those really long WBS charts and detailed Schedules — all those things the developer is working to. It represents all the “getting it done.”
I’m not sure he left feeling the “ah-ha” that I’d hoped he would feel after my explanations. Perhaps I wasn’t as clear or as insightful as I’d hoped. But perhaps it sets a stage so that the next time the PM is pulling her hair out, he can understand that a little better.
 I’m preparing to review Cornelius Fichtner’s PMP exam preparation package called “PM PrepCast.” Cornelius runs the web site, http://www.project-management-podcast.com/. I’ll be writing soon about my impressions and how I’d such a package fitting in one’s PMP exam prep, comparing it to my classroom prep experience, and musing about its use for the environment that I care most about, Cottage PM.
Early Impressions
I’m encouraged. I’ve been a free subscriber to Cornelius’ podcast for a while. I enjoy listening to it, and a few others, on my daily commute. (I put the podcast on my MP3 player, pull out the knitting, and knit and listen for 40 minutes. Yes, I knit. I write about that on my personal blog, www.MaxWalker.name. But enough about knitting. Back to Cornelius’ podcast.)
I’ve been impressed with the quality of information provided at PMPodCast. So, a few weeks ago, I took a moment to glance at Cornelius’ “Try It Free” section the web site. The first impression was really good. Very organized. Appears thorough from the first look. And appears to have the same “consumable” and approachable quality of the podcast.
Happenstance
Then, as it happened, I ran into one of my organization’s PMP candidates, Dean, last week at work. Dean’s been preparing for the exam for quite some time the same way a lot of us do — we start, we stop, we start again, we stop, then we finally set a goal and get serious. Dean’s serious now. Having already approached Cornelius about such a review, I mentioned PM PrepCast to Dean. To my surprise, he already had PM PrepCast, he said. I started to dig down a little to see if it was the same package or not. He reassured me that it was, and was able to refer to Cornelius by name without even thinking about it.
Dean told me how impressed he was with the package. He bought it quite some time ago and has benefited from Cornelius’ free updates to package owners. It’s Dean’s primary tool for prep, and he’s been really pleased.
So, now I’m all the more excited to review the package.
In A Hurry?
But if you’re in a hurray, I suspect you could certainly get the package before I write about it in more detail. One learns to trust community response and feedback, and Cornelius has good response and feedback from the community. Compare to many other PMP exam prep choices, Cornelius’ PM PrepCast is very economical at $99. I paid a lot more for my classroom prep course.
————–
For the record, I am signed up now with Cornelius as an affiliate, so the links here are affiliate links. If you buy the package through these links, I’ll get some Pepsi money.
OK, I promised you another story on self-interest. Here you go.
Ethics — c’mon, keep reading
Let’s start with discussion ethics and those pesky ethics statements. Some whine about it, and I’ll concede that ethics statements are usually way over-though and over-stated, and even if you agree with them, you still often end up rolling your eyes with a “Really?!” kind of response. You agree, of course, sincerely, and both in form and in intent, but the statements can seem so out there. Such was my reaction to the PMI Ethics Policy that you sign upon becoming a member and that you sign again when sitting for the PMP exam. (The test questions on ethics can be particular amusing, errr, frustrating, because they can so unpredictable and situation-dependent. But moving on.)
But I’m grateful for focus on ethics and reminders on them. One is always grateful as one observes the lack of ethical behavior.
The Story
A few years ago, I worked in an account management role. As in many teams, you had those team members who were the acknowledged stars, the right-hand to the team leader, the ones who always seemed to have the roughest customers and handle them the best. I learned that things are not always what they seemed.
We had 2 such team members. Let’s call them Bill and Joe. Their customers were always in a state of escalation. There was always a crisis. We were all aware of it, and always duly impressed with how Bill and Joe handled these irate and uncontrollable customers. They were always on escalation phone calls with the customer and the VP. They had to get extra resources assigned to solve problems. They frequently got upset themselves and threw their own tirades, but that’s just an aside.
At one point, Bill moved on to another position in the company, and Joe took over many of Bill’s rough customers. Later, Joe left the company, and his customers were reassigned to another account manager. Let’s call him Tim. Tim was a mild-mannered fellow whose customers were never hollering, never yelling. It was perceived that he had easy accounts.
As was the norm, Tim approached the main contacts at these accounts, the same contacts whose names we all knew because they were always making so much noise. Tim approached one of these customers and introduced himself. Through conversation, Tim was surprised to learn that the customer didn’t even know Joe’s name. Didn’t know what role he played in our account relationship. And the customer expressed a general contentment with the company and services provided. Over time, that proved true; the customer virtually never escalated again.
The Conclusion
Bill and Joe had snowed us over. They’d created crises to gain visibility and notoriety. And it had worked for a long time. The leadership at the time was slow to catch on to the dynamic, even after that experience. It was explained away. And trusty Tim was eventually let go when budget cuts required staff reductions. He was apparently not perceived as valuable enough, he who could manage accounts so smoothly as to never create crisis, and who could resolve crisis so ably that no one ever heard of it.
So What?
OK, so what’s the message for Cottage PM? Two things jump out at me today. One lesson from Bill and Joe, and another lesson from Tim.
- First, well, ethics matter. Integrity matters. This kind of unethical behavior may appear to work for a while, but at some point, it’ll become clear that you’re not creating value. It will erode your project team’s trust in you. Motivation will fall. Results will suffer.
- Second, communication matters. And that ties back to my previous post on communication. Tim was so quietly effective that he may have been undervalued. (I wasn’t involved at a managerial level, so I can’t speak to the decision process there.)
There is a valid self-interest that pairs very readily with an organizational self-interest to communicate well in your projects. Your leadership does need to know what decisions you’re taking, what problems are surfacing and being solved, what priorities are shifting, resource challenges, etc. You’re professional. You can communicate that without whining and without an obvious self-pat on the back. You can communicate it legitimately and sincerely in light of the organizational needs for that information. You can be sure your project team gets credit for their good decisions, avoidance of risk, handling of crisis.
And it strikes me that while that communication is important on any project, it may be particularly important in a Cottage PM environment where there are few norms and standards for projects themselves, and where an organization of even really talented people may not anticipate problems and downstream effects of project decisions.
So in the absence of set project expectations, leverage the general communication methods of your organization (if they’re generally effective). Use established communication norms. If you’re an email culture, do email. If you’re a reports culture, do reports. If you’re a meeting culture, do meetings.
But whatever it is, do it.
Seems like everyone is talking about project communication and the soft skills of project management. One of the things that attracts me to the PM practice is the all-encompassing nature of it. To be effective, one has to understands projects, yes, but also general business, one’s own industry, contract norms, people management, financials, etc.
And you better be pretty darned good at communication.
And that goes double for a Cottage PM environment where the formalities for project selection and project charters and scope statements and such may not exist.
The Story
Here’s my story from today to back this up.
I work in an Operations group. We provide some process support, customer support, project support, and technical development for certain business and services units. We’re a Cottage PM shop. That is, we do a lot of projects without the rigor of any PM standards or norms. We have really talented, go-getter people, and we get some amazing work done. But as our success and responsibilities grow — yeah, those go together — we sometimes get bit in the behind from some of that lack of project formality. Like you, we have to figure out how to scale the big-PM thought that dominates PM literature, training, and certification down to a functional level for our environment.
So what’s up with communication today (the literal today, not the figurative today)? The principle is this: you gotta make sure that your sponsors / leadership / stakeholders understand properly the level of work involved in the projects. When you have a standing Operations team like ours who own most of these projects, it’s easy to forget that resourcing is still just as real a challenge as if you were hiring out for resources.
The Problem
Today, a colleague and I were visiting about a communication challenge. As in most project environments, including Cottage PM environments, there are many more desired projects than we have resources to work. Prioritization is a constant challenge. My colleague was lamenting that leadership was wanting two major projects by the end of the month. One had been prioritized above the other because it involved a hard date for customer announcement. The other is still wanted. What came to light in recent conversations, though, was that the business leadership had through that we were working only on that 2nd project. Leadership was apparently unaware of the technical work that had to be done — and was being done agressivley by a virtual team of at least 3 people — for first, higher priority project.
We had shifted our priorities to match the shifting business priorities with such efficacy that the leadership didn’t even know it.
On the one hand, that’s awesome agility! On the other hand, communication didn’t accompany the change. The impact of that shift was not called out, wasn’t known, and as a result, expectations didn’t shift with that shift in priority, and now there’s a problem.
As project managers, we have the functional need and the ethical duty to be sure that those expectations shift, too. Duty? Yes, duty. And not just because of expectations. It’s because the organization leadership really needs to understand how its limited resources are deployed and to have the freedom to exercise its own ethical duty to allocate those resources to the benefit of the organization.
Now What?
As my colleague and I talked, I discussed with him the use of a WBS as a means to do that communication. The WBS exists for these projects in one form or another (remember, we’re a Cottage PM environment in which there is no particular standard or practice for such things). But the WBS is not usually in a form that can paint a picture for leadership. And it should be. It’s a critical communication tool, not just a planning and control tool. So my colleague and I identified 3 things to address this problem:
- First, he’s going be diligent about a written Charter/Scope document to define the project and its borders at the beginning of the project before work begins. (Our organization won’t support the oft-touted rigid processes of written and signed Charters followed by Preliminary Scope Statements, then Scope Statement, then who knows the heck what, so this combined Charter/Scope idea is probably and appropriate scaling of those processes for our environement. We’ll see how it goes.)
- Second, we’ll explore using pictorial WBS geared toward communication. To do that, we’ll leverage some of the really good, straightforward recommendations from Josh Nankivel’s WBS Coach package.
- Third, we’ll be more diligent about project closure where we sit down with the leadership, pull out that Charter/Scope doc, and prove the results.
If you look at it, it doesn’t really add that much work. That work is already happening. But it happens so informally that memory shifts, priorities shift, crisis takes over, but things only ever get added to the plate; nothing very really gets prioritized off the plate.
It’s important to note that there are both self-serving elements at play and altruistic elements at play. And that’s OK. Just don’t let the self-serving aspect overtake the altruistic. It’s your job to keep them aligned and heading the same direction. I remember a college history class that discussed the idea of “enlighted self-interest,” and that’s probably what we’re talking about here.
I’ll write again about that self-interest gone amuck in a little while. Got a good story on that one, too.
|
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.
|
