Getting to a Plan
There is one thing that everyone wants from his or her project manager: the project plan. But the plan is not the project bible! Sorry, but it’s true. The Scope of Work (SOW) is the reference point for everything that is going to happen on the project. Sure, you need a good plan, but you need some time to formulate a plan that will work for everyone.
At a previous job, galaxies away, I was handed a slide from a sales pitch that included a list of deliverables with dates attached to them. I was told that this slide was the project plan, and that I needed to figure out how to make it work. In my mind, the dates were never going to work. But the scope was signed and the dates were a part of it. Yeah…there were a couple of problems with that situation.
- The SOW was signed without a project manager reviewing the plan (or the project budget, for that matter)
- The client had very aggressive expectations of the time needed to compete the deliverables in the SOW, and the team who would perform the work was not involved in the pitch.
- The budget was really not enough to cover even the first two phases of work. Gulp.
So, my challenge was to turn a list of deliverables and dates in to a successful project: a site that delivers on the client’s goals, on time and on budget. Honestly, it was a huge challenge. How to even begin? I cried and went home. Kidding. I took a few hours to myself and assessed the situation. I needed to figure out what was going to make the project a success. Below are a few steps that helped me.
Stop and think.
Before you start, you have to stop. Take a deep breath, print the scope of work and all details that come along with it (maybe an RFP?) and read. Be thorough-understand the details and ask thoughtful questions before you get in front of the client. The last thing you want to do is be the project lead and seem ill-informed.
Do some pre-planning.
I always like to take some time to think about the project and its goals, and analyze how they are laid out in the SOW. There are multiple ways to execute the work. I’m not saying that I think about potential IA and Design. Never. I think about the tasks that are outlined in the SOW and try to come up with a project approach by sketching something very high-level on paper. Yes, paper. I always have a calendar handy for reference (thanks to the iPhone I no longer carry a print calendar).
I have found that a sketch of a high-level plan including deliverables, timeframes and resource ideas comes in handy when I sit down to create the project plan itself (I currently use OmniPlan). It helps me to organize my thoughts, formulate what might work for the project, and then transform them in to a discussion. For me, this all leads to the plan.
I also like to be realistic at the point of pre-planning. It never hurts to approach a client with a realistic plan for what can be done in a certain amount of time. I never like to have that awkward “we might miss the deadline if…” conversation, so a realistic view of the project and its tasks, presented in what would normally be considered a reasonable timeframe is always good to communicate (even if it’s not realistic to the client). Honestly, wouldn’t you rather commit to something you are comfortable with?
Talk to your peers
If there is one thing that I will repeat over and over again on this blog, it’s that project managers need to communicate with their peers. Starting a project internally needs to begin with clear communication of the project goals and effort required in meeting those goals. This comes with understanding the fact that a project manager can’t (always) plan the project on his or her own. I also don’t think I could ever take a plan to a client without knowing that my team is at least aware of, or comfortable with the plan I’m about to present. Doing that would be like stabbing every single one of my coworkers in the back. Not so good for the old reputation, I’d say.
I also like to utilize the super-smart folks surrounding me and get their input on how the team can complete the tasks at hand without killing the budget and the team’s morale. Yeah, we can decide on Waterfall or Agile approaches, but when it comes down to it I need to know that we can realistically execute the plan. Can designers start designing concepts while the wireframes are being developed? Will it make sense for this project and for the team? ? Can we have two resources working on the same task at once? There are so many questions that the project team can consult on. I would definitely have this conversation with a thought in mind—after all, creating the plan is my job. Running ideas by the team and having an open dialogue about the approach can help in planning the project, but also in getting everyone thinking about the project in the same terms. It gets them ready.
Get to it!
When you’ve got all the info you need and you’ve spoken to all parties, you should feel more than comfortable enough to put together a rock solid project plan.
Sometimes a good next step is to put a communications plan together. As the PM, you need to know how you are going to manage the madness over the term of the project. Your team will be looking to you for that support. For the project I mentioned above, I ended up doing a daily check-in at 10am. I sent out a status internally to the team every morning just to be sure that all parties were aware of every moving part—especially because we were working with resources in different cities. Oh, the complexity!
Enjoy the ride
Every project is a unique snowflake. Sometimes they are smooth and alarmingly easy to manage, and sometimes they are a complete nightmare that wakes you up at 3am every other night (totally happens to me). Regardless, plans change. My philosophy is to be easygoing and adaptive. Otherwise, the daily changes will cloud your vision and you’ll focus on the things that won’t help your team, your client and the project. And remember: project managers can have fun too!