Ah, those small, short, simple projects. (Aka in this blog, shorthanded as SSS for convenience.) Easy to manage! No paperwork! Just do it!
Well, kind of. Certainly less paper (documentation) required than a larger, more complex effort. Certainly may be less formal In communication, easier for the team to do more verbally. I am 100% in favor of "just-enough PM" for the effort at hand.
But what about when a smaller, simpler, and/or shorter project is a part-time, "background" effort for a lot or all of the team members?
To me this is a special case of those "easier" SSS projects. (I put that word in quotes, because little projects can blow up too - and it doesn't take much to make a 3 week project late by 100 - 200%!)
Here are the real-world-effects that can plague SSS projects, especially background ones:
- The supposed easiness of the project and time issues of part-time team members lead to a weak start, with cursory or non-existent discussions of goals, priorities, stakeholders, risks and a plan. Possible impacts: Lack of clarity on what, why, who, and how for the project. Basically, lack of a strong foundation that could turn "easy" to problem-plagued right out of the gate.
Team members are popping in and out, fitting in work here and there around their bigger focused efforts. Possible impacts: a) "Loss of lock" on the goals, priorities, and scope of the project. (Scope creep, anyone?) b) Misunderstandings, leading to missed details. (Rework, anyone?)
- Multiple team members with sporadic attention to the project. Possible impacts: the above effects, multiplied.
- Remote team members who are practically unavailable for real communication, given the combination of their part-time work on the project and time-zone differences. Possible impacts: the above effects, growing exponentially toward outright craziness.
Easy SSS projects, you say? :-). Not so fast! Let's protect ourselves. And it can be really easy.
I don't know about you, but when there's a lot of stuff flying around, many Mondays I can barely remember what I did the previous Friday. In busy times with multiple simultaneous projects, what we need is a way to make sure we don't neglect a strong start, and then help our brains stay on top of key details (requirements, deadlines, specific decisions) from each effort we owe things to, and stay clear on the context for those details (customers, project goals, reasons for priorities and trade-offs). We need something concise that we will actually use to lead strong-start discussions even though the project is SSS; and that team members can then keep handy and whip out at any moment to refresh and engage fully with that SSS effort.
On a larger project, this would often be the Project Plan Document (or Project Management Plan document) - a summary document that provides an overview of the project including its justification, scope, team makeup, major deliverables, major risks, and other info. Meant to help communicate the essence of the project to anyone who needs it (including busy, fragmented part-time team members if necessary.)
But in my experience this is the doc that often gets happily tossed when a project is designated SSS. Yay! Don't have to write a big plan doc! (Or in the case of an SSS project, even 5 pages could feel like bureaucracy.)
One way to protect ourselves on SSS projects is to not throw out that project plan baby with the bathwater, and instead, use a ridiculously short and concise project document that can be our fragmented team members' "re-entry cheat sheet". Here's what I'd want my part-time in-and-out team members to be fresh on at the drop of a hat:
Goals: What is the project meant to accomplish for the group spending money and time to get it done? What benefits is it meant to provide to its “customers” (who are they and what is most important)? What's the scope -- what's "in" and what's "out"? When do we need to be done and what can we spend? (We all need to stay clear on all these things so that no one's work goes off on a tangent.)
People: Who's doing what on the project? Who cares about it and why? (We all need to be aware so that we can keep them in mind and keep them in the loop.)
Risks: What could go wrong in each of our areas? What should we be doing about it?
Process/plans: How are we approaching the project together? (Having meetings or calls, other communicating, monitoring progress, giving status, controlling changes, doing reviews). What are the key deadlines we need to meet?
To get to the punch-line of this post, I have become a huge fan of using a one-sheet version of such a document for SSS projects - and even as a communication tool on some larger ones that do have a normal project plan document, when there are certain people (e.g. executives) who still need a very short, fast-scan, mini-Cliff-Notes summary of that project. Goals, People, Risks, Process/Plan -- short and lightweight, but it's all there. These sections give some basic structure and clarity to a small effort. And the format makes it easy to scan. Here's a link to the template file that includes several variations of a one-sheet project doc with these sections.
Every item on the sheet is worth at least thinking through for any SSS project. Sometimes that's all I do, if the SSS project is in house, we're pretty focused on it, we can have good frequent discussions with everyone there... But if it's a background SSS project with multiple part-time in-and-out team members, and especially if anyone is remote, then I create an electronic version of this micro-plan and make sure everyone has a copy.
Voila - a quick and easy way to literally stay on the same page, even on the projects that are sporadically getting small amounts of our time and attention, and help reduce confusion, aggravation, and the attention-deficit-blow-ups that could result.
This has worked well for me, including for my own brain when *I'm* the one who is fragmented across multiple simultaneous efforts and therefore highly part-time on some. I offer it up in case it might help you too!
Link to template file: One-Sheet Project Doc - Multiple Formats