I want to expand on my first post in the Project Management Series, about what I called Project Fog. In that first post I mention the role of the Project Manager (PM). But what are some causes of the foggy front end of a project?
First, some background. I’ve been fortunate to lead projects ranging from ERP implementations, product development projects and business integrations. You can peruse my LinkedIn profile to see more details. All this to say that I draw from experience across differing industries and functions. It’s an observation and a style that has worked for me and maybe will for you too.
The Foggy front-end boils down to two main components; Team and Requirements. How do you construct a team if you don’t know the requirements? How do requirements get refined if you don’t know the team? Compounding the fog, the PM isn’t always first on the scene. There is enough clarity of what the end might look like, but getting from where we are today to that utopian goal is foggy.
I liken Project Fog to an early RPG video game, where the computer and graphics engines aren’t powerful enough to render an entire scene with the clarity and detail the player would want or need. Thus, the player only sees enough detail as relevant at the time. As they walk through the world, the fog moves away revealing more detail necessary for the game to proceed. Maybe an Ogre over there (stay away), and sword over here (pick it up), a pool of healing potion (remember where it is for later). As the game proceeds, the player gains more clarity to what they and who they need on their adventure. Where they will go and how the team will achieve their goal.
Similarly with a project, but it isn’t just one player. It’s a team. The Project Manager is leading that team. What appears to be clear for one team member may not be clear for another. And clarity could be lost from one scene to the next. The PM plays a huge role in providing the clarity between team members. And also knowing when to step out of the scene and let the team work the project tasks directly.
The team sets forth, still recognizing that there will be fog…
The PM also builds the map (project plan if you will). Working with leadership to define the initial scope, and goals then sharing with the team. Building these initial maps helps the PM, and leadership identify the team. As the teams takes form requirements are refined and team members adjusted. The map at times looks complete but realizing it is dynamic the PM is always prepared to adjust.
One of the most powerful tools to the PM in this stage; communication. Up, Down & side to side. I’ve often referred to this as the PM translating English to English. But that is a topic for another beer. Communication is the sunlight that burns the fog off the foggy front end and enables the team to start cranking on the project. The speed at which the fog can be burned off the sooner the project really starts to move.
Essentially the PM is building out team and requirements a bit iteratively. That map is the requirements, it’s not complete, can’t be complete (because it’s foggy), but is complete enough to build a team. The team adds to the map, identifying new requirements and so on.
At some point there is enough team and enough map to begin the journey. The team sets forth, still recognizing that there will be fog and being prepared to continue to tackle the fog makes the team stronger. The fog burns off, and the journey proceeds at a faster pace.
By recognizing there will be fog and knowing what forms that fog, we as PM’s are better prepared to deal with it, inform and educate leadership, build trust in our team, to tackle the tasks at hand.