Some of the fundamental skills of Project Management and life may seem basic, but like most things, it's the repetition that causes us issues. There are people in the world whose makeup allows them contentment in discipline and repetition. I am not naturally one of those people. Discipline and routine are skills hard learned for me - and I continue to learn them every day in my job, but what I do have is grit - I will not give in to a problem that I believe can be fixed!
Often in agency life, there is a lot of vagueness and short-term plans, seeing beyond the end of the month or two months is about as far as you get. For the Project Manager this can feel like a lot of uncertainty at times, especially when, in your previous roles, timelines could be six months or two years out. Things can change fast, shiny new projects come along that people want to work on and it can be a challenge to get to the end of something less immediate.
This is where the grit comes in. Putting in the time to eke out a detailed project plan that will take you from initiation to retrospective can be a big help, even if you don't have all the details to start.
1. Start from where you are
Making a crappy first draft is how we most often overcome uncertain situations, allowing ourselves a version of something that is supposed to be mediocre breaks the fear of getting it really wrong.
To do this I jot down, in any format; on paper, a slide or a whiteboard, all the muddled aspects that are clamoring around in my mind. Some of these might not even seem relevant to the situation in focus, but they're better anywhere else than in my head.
For example - I need to plan a Ruby on Rails upgrade but my team is too busy to help me build estimates and I’ve become stuck. The plan is due for the client in the morning and I've spent enough time ruminating on how terribly I've made a mess of everything!
On my messboard, I put down all the things I already know and mark all the things I need to find out about with an asterisk:
- What's the client's current version? How big is the application? *Are there dependent third-party tools or older Ruby gems? Does the client have any big launches or high traffic periods coming up? Is the team familiar with the current application? Is the code base shared with other third parties to work on?
- Will I have anyone available to work on this? What do I need to shift around to be sure I can have enough people on the problem?
2. Reduce, reuse, recycle
Historical data is hugely beneficial for this process, looking back over old projects of a similar size can really speed up the detangling process. When I can look back and see a previous project took X number of hours and where the most problematic aspects were, I can get a much better feel for the complexity of this type of project.
My next step is to put all my messboard items into a list and rank them by priority:
I cross out any of the thoughts I've added that are not directly part of this problem (I usually put these on another list)
I then number the most time-critical questions I need to answer in priority order.
I split the questions into those I can answer myself (and answer them) and those I need answered by others and send them out as fast as possible. If I can't get the answer in time for my deadline I include those as risks in the project plan/communication to the client
I build out the plan as best I can to illustrate where we aim to be and when we aim to be there - for me this is best done as a Gantt chart since it shows the timeline for our client to get on board or to ask questions.
3. Affirm or Reject Assumptions
Ideally, the next step is to get some of the team to review the plan, even briefly, to make sure I haven't left anything critical out or made any major false assumptions. Unfortunately, sometimes there just isn't time for that. If it is the case that I’ve worked on a plan alone, I like to point that out to the client for transparency.
Sharing with the team at this point has a number of advantages:
- It shows that the PM has put in the effort to ease the burden on the team by making a clear plan to set client expectations.
- It allows the team's voice to be heard and helps get everyone on board with the plan of action.
- It demonstrates to the client that you've thought out their request and are fully engaged with what they want to do.
- If the request is much bigger than the client initially thought, it can help to reveal how high or low of a priority the work is for them.
4. Fill in the void
In all teams and groups of people, it can be hard to always fill the void. When there isn't clear information available, people will often fill it with stories they have pieced together from the context they do have. For example, a team member might perceive that a piece of work or a project is a low priority because you're not talking about it with urgency. Or a client might feel that the request they have made is much smaller than it is because they haven't heard you say otherwise.
Sharing the plan with the team and the client - listing risks and assumptions where possible and getting everyone signed up puts everyone on the same page.
5. Grit down and get it done
It doesn't stop at the plan – following through on execution is a particularly grit driven endeavor. Slowdowns, delays, and changes in scope or direction can deflate the motivation and shininess of a workflow.
As a project manager, this is where you have to knuckle down and generate a sense of focus - to keep bringing a positive view and curbing unnecessary, negative talk about the work can be hard going when things are getting stale.
I've found it useful to reiterate to the development team the value of getting the work completed, sometimes adding daily check-ins specifically on this piece of work can help to keep focus and short-term goals.
I like to celebrate small milestones as they come up and not get too deep into small regressions - just keep moving forward, when the work’s done you can reflect in a retrospective but for now, put your head down and get to the finish line.