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.
Related posts:
Category: 
