|
|
One of my avocations is directing choirs. I’m currently preparing an Easter-time performance of Rutter’s Requiem with a small choir of about 20. (Not nearly enough voices, but that’s not relevant to this writing.) My choirs are generally smaller than I’d like. Mostly because I won’t beg grown-up people to sing.
As a PM, you’d think I’d know better and be just fine with begging for resources, and begging resources directly. 
Choirs and Project Teams have a lot in common
Last night, it struck me that one of the challenges with rehearsing a choir is similar to some challenges faced by project teams.
In a volunteer choir, you end up with mix of skills and talents. Invariably, you end up with a certain set of the most talented who think that they don’t need to attend the full rehearsal schedule. Since “they know that piece already” or “they’re quick studies,” they think they can simply show up at the last rehearsal or two, add their considerable talent to the lesser singers, and save the day.
OK, that sounds a little bitter. Let’s try that again.
They feel that there is no particular benefit to them or to the choir for them to show up and sing effortlessly through the early rehearsals where others are learning notes, etc., and all that they or the choir really need from them is to show up for the later rehearsals where the polishing and put-together supposedly happens.
They’re wrong.
Projects are group creative processes
One of the important aspects of a choir is that it’s a group learning effort, a group creative process. That fact is demonstrated by the attendance requirements and policies of the most accomplished of choirs and ensembles, including the likes of the Mormon Tabernacle Choir, The Cambridge Singers, or The King Singers. Each is composed of arguably the best ensemble singers in the world. Certainly, they’re each fully capable singers. Presumably, many of them already know the music being sung in many cases. And they’ll each represent the most “quick studied” among “quick studies.” They learn quickly; they pick up material quickly.
But those are just entry qualifications. From there, the choir begins the group creative process. In these professional groups, if you don’t show up, you’re out. Not showing up cripples that choir’s ability to create what it seeks to create musically.
I think the same principle applies to project teams, and many project team suffer from the same perception among its more talented members.
The project team needs time together to build the vision of the project, develop the project plan, and to manage and respond to risk and change management.
The absentee project team members create rework
The more talented of the team may believe that the rest of the team can do all that soft stuff, then they’ll simply show up at the end to do their part, to deliver their own deliverable. But swooping in at the last minute in a highly-skilled but near-complete ignorance deprives the project and the project team of the group creative effort that makes up a successful, insightful project that creates real value for an enterprise.
And those prima donna singers that show up at the last moment? They completely change the character of the choir, which influences the musical interpretation and the group “rhythm.” Suddenly, the group has to relearn things as a group once a new singer is introduced. Musical entrances and cutoffs have to be adjusted. Relative dynamics may suffer.
It produces a lot of “rework” in a choir. And it does the same on your project when you have absentee team members.
Solutions? You got me…
How do you solve it? Well, I haven’t solved it completely yet. Not in my choirs. And not in my projects. But with this clear metaphor in mind, I think I can manage that risk a bit better in future.
 I finally finished reading, “The Tyranny of E-mail: The Four-Thousand-Year Journey to Your Inbox.”
Loved the book. It was a very interesting read about how communication has changed with the advent of, well, literacy, then postal service, then typewriters, then telegraph, and finally email. At each step, certain core assumptions and behaviors changed in our society. It was fun to read about the historical complaints about piles of written correspondence to manage, complaints that were nearly word-for-word the same as modern complaints about email volume. There are great tidbits throughout the book that can improve how you balance your email and control it instead of it controlling you.
In my organization, we’ve begun adopting some email best practices as outlined in another book, The Hamster Revolution: How to Manage Your Email Before It Manages You (Bk Business). Freeman makes very similar recommendations throughout his book, “Tyranny.”
They’ve probably leveraged some of the same research.
Any challenge to effective communication will be a challenge to your project, and email is a primary communication channel (pit) for many of us these days. So managing it better can directly impact your project.
In the final chapter of “Tyranny,” Freeman makes some recommendations under the general title, “Don’t Send.” Here they are, with some of my ideas of how they relate to your projects.
| Rule |
Project Application |
| 1. Don’t Send |
Sending less means you get less. Sending less makes you focus communication and make it more meaningful. It makes you consider alternative channels, such as short meetings or phone calls that may be more effective. |
| 2. Don’t Check It First Thing in the Morning or Late at Night |
Less about projects, and more about your ability to manage email instead of it managing you. Give yourself the down time. Let other things e more important for a few minutes. If you can let your mind run free, you may find new ideas for solving some project problems. If your mind is constantly spent on email, it can’t be spent on other things. |
| 3. Check It Twice A Day |
You set your agenda for the day instead of letting email set your agenda. Make email an item on the agenda, not the other way around. Be fully engaged on whatever you’re doing, including being fully engaged in email when it’s time to do email. Your emailed status updates will likely be better. Your project scheduling will also turn out better if you’re not constantly interrupted by email. |
| 4. Keep a Written To-do List and Incorporate E-mail into It |
OK, I’m not yet sold on this. Breaking most time management rules, I have multiple to-do lists, or multiple inboxes, as David Allen talks about in “Getting Things Done.” I manage a To-do list in my email box and after some trial and error, it works quite well. I’ve also developed the discipline not to pounce on every new message in the in box. I’m just fine letting them stack up and getting to them later when I’ve planned on it. So, managing a To-do list in my email account has worked OK. You judge for you. The idea is not to digitize the list, Freeman says, and to separate the time management from the technology, subjecting the email to the list and not the other way around. |
| 5. Give Good E-mail |
Write clear subject lines. Write short emails. Action items up front. |
| 6. Read the Entire Incoming E-mail Before Replying |
Duh. But you know you’re guilty of not doing it. You’re more apt to provide meaning email (see rule 5) if you read it through. Then, you can give a proper answer. You’re also likely to come across as much more civil and in control. No one trusts a harried PM, so be sure you don’t look harried in email. |
| 7. Do Not Debate Complex or Sensitive Matters by E-mail |
That goes double for project communications. In my technical shop, we stumble over this all the time, trying to troubleshoot or replan a design via email! 30 minutes and 30 messages later, everyone quites ready except a few die-hards. Schedule a meeting. |
| 8. If You Have to Work as a Group by E-mail, Meet Your Correspondents Face-to-Face |
Yes, really. If you can’t fly them in, then use SKype or other video chat service. Spend time together, even virtually. Make time for the niceties in meetings. Celebrate personal things like birthdays or weddings or grandchild births. Help the team see each other as people, not resources, and business runs more smoothly. |
| 9. Set Up Your Desk to Do Something Else Besides E-mail |
Make your computer subject to your workspace, not the other way around. Leave room on your desk for thinking. |
| 10. Schedule Media-free Time Every Day |
“We were not born to e-mail, download, watch YouTube, and play online games,” writes Freeman. Be aware of the other things in your environment, in your life. Be present there. My best ideas on projects come while I’m knitting on the car pool on the way home. (Yes, I knit.) Or while I’m doing homework with the kids — which I don’t do nearly often enough. I’ve learned to take a pad of paper with me to the soccer game, because as I relax and my mind relaxes as I enjoy watching the kids, ideas pop into my head — ideas I wouldn’t have had if I still had a Blackberry. |
About 15 years ago, I had a regular, friendly argument with a colleague. We’d be on our way to lunch, and he’d be telling a story about a tense customer interaction, or any kind of stressed business interaction, maybe where he had to deliver some bad news or correct a customer’s expectations, or something. He’d wrap up the story with an emphatic philosphy statement, “Hey, it’s not personal, just just business!”
I always challenged him on that. I never won him over, but it became kind of fun to see him get all red-faced when he couldn’t convince me.
I maintain that it’s all personal. Business is about people. You’re selling to …. wait for it …. people. You’re buying from …. wait for it … people. You’re managing … wait for it … people. You’re working for … well, you get it by now.
It’s all about people. Therefore, it’s all personal.
Now, that’s different than “taking something personally,” which denotes a different issue.To be clear, let’s talk in terms of “sender” and “receiver” in this writing. Some kind of communication is being delivery by someone to someone else. Taking something personally is on you, the receiver.
But the idea that “it’s just business” is on you, the sender. “It’s just business” gives you license to ignore the other person’s, well, “person-hood.” It gives you license to communicate badly, coldly, impersonally. It may give you license to take actions you might otherwise reconsider or restructure.
You can never forget that you’re working with and talking to people. You still have to deliver bad news and corrective communication sometimes, and you shouldn’t shy away from that duty. But remembering that the person to whom you’re talking is a real person may help you deliver that communication better — not more softly, not watered down, but better, more completely, and with more empathy where appropriate.
It is business, yes. But business is about people. Take your employees, your project team, your customers, or your stakeholders for granted and treat them like “resources” as though they’re replaceable (I got plenty of new customers coming all the time, so I can afford to mistreat you lot) and you’ll soon find out how well business runs without good people.
Case in point.
Last fall, my very trusted mechanic sold his business to a fellow from out of state. The shop manager stayed, with the short-term (unwritten) promise from the new owner not to fire him or a key mechanic in the shop. This shop owner has a real gift of taking care of people — customers and employees alike. He’s the kind of guy that will come get you in the middle of the night if you’re stranded, just because you’re a customer. He’s the guy who takes care of things quickly and equitably for that soldier’s wife while he’s deployed on the other side of the world. Soldiers come home, shake his hand, and say thank-you. Fathers come thank him for taking care of the teenage daughter who was alone one weekend and had flat tire.
The new boss finally fired the shop manager just before Christmas last month. Seems the new owner perceived — and I’m quoting, albeit second-hand — “We don’t have any good customers.” The shop manager couldn’t let that stand, and they discussed it for a while, and since their perceptions were not and would never be aligned, he was let go soon thereafter.
It’s valid enough to say that we need to cultivate a new customer group, a more profitable customer segment, etc. But there’s something dismissive and telling in the idea that “we don’t have any good customers,” especially with the high loyalty the customer base demonstrates. And as the news spreads, that loyalty is walking out the door. It belies a certain disdain for one’s customer base. Dangerous ground for a businessman.
Sure, it’s business. But business is about people. And this “bad customer” now goes elsewhere, as do many others. Too bad the shop manager is changing industries; I’d cross the valley to do business with him.
It’s often touted as a weakness and a risk, and I agree that it can be so, but I argue that in our Cottage PM environments, the “working PM” has a distinct advantage.
The “Working PM” is the project manager who not only owns project management tasks on the project, but also owns other project deliverables. He is both PM and project team member. It can go even further: we may function as Project Sponsor, too!
The risk, of course, is that by owning non-PM work on the project, the PM work gets robbed of the time attention it needs. That’s real, and you need to watch for it.
On the other hand, as a project “insider,” owning part of the work, and possibly owning the project outright as sponsor, we’re uniquely positioned to do some things better than “traditional” PMs sometimes do. We are better positioned to identify and drive the end value of the project.
Projects have to create value
This is related to one of the lessons learned for 2009 as listed in the article, “In Hindsight,” in the January 2010 issue of PM Network (p. 33). That lesson is metrics. But drilled down further, that lesson is metrics to drive real value-add in our projects and proving how the project gains value for the organization before securing funding. State more directly, as quoted in the article:
“It forced everyone to think like a businessperson, to look at the value proposition of the project, what problems it’s trying to solve, and what the benefits are to the company.” –Karen Quagliata, PMP.
Value. It’s not just about the triple constraint of Cost, Time, and Scope. It’s about what value is created after (while) focusing successfully on Cost, Time, and Scope.
Use the Project Charter tool
Earlier this week, I wrote about my emerging affection for the Project Charter tool. That tool is key to this value analysis. It identifies the problem statement and a high-level view of Cost, Time, and Scope. That early snap shot is key to knowing what value you’re creating, and that perspective increases your value to your organization.
Remember recently when I wrote a little about project charters? And I said I was going to say they’re not necessarily relevant in our smaller Cottage PM practices? And then I changed my mind just before I wrote that?
Well, I just reconfirmed that experience. And I’m finding that I’m a new fan of Project Charters in Cottage PM practice!
I have a key organizational objective — one of those really visible ones — to deliver this year. I’m delegating that project to a staff member as a career development item (PM isn’t his day job, but he’s picking this up as a project to grow a different skill set). To do that, I decided to write a proper project charter for the project. Today, we reviewed that together (me, the PM, and the manager who owns the application in question). Here’s what I learned through the process:
- The rigor of writing the charter caused me to changed even my own understanding of and intentions for the project scope. That surprised me; I thought I had it all nicely defined in my mind. But clearly, if it wasn’t so clearly defined in my mind, then there is no way I could have ever communicated that high-level scope properly!
- The rigor of reviewing the charter together gave focus to our scope conversation and let us have conscious, stated agreement to the formal problem statement and the high-level deliverables. We refined both slightly, reflecting our growing group understanding.
With all the document structure, the doc is just over 3 pages long, but the meat of it could fit on a single page, which I think would be better, but we’re using an peer organization’s template to try to support a modicum of consistency.
Now, we’ve scheduled a review the formal sponsor. The PM is building a project workspace in our Novell Teaming implementation to house the Charter, future docs, action items, meeting notes, etc.
I have to admit that achieving clarity so early in a project feels a bit odd. I’m excited by it, and intend to use project charters on all these small projects from now on!
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.
|
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.
In some cases, I use "affiliate links" and receive a nominal referral commission. I only link to resources that I trust and recommend personally for PMs like me in the "Cottage PM" space.
|
Category: 
