Blog

We know it today as the Gantt Chart, but historical research credits a visual network diagram of inter-related activities was illustrated as early as 1896, by Karol Adamiecki. A Polish engineering and management researcher, Adamiecki developed the Harmonogram technique while working on steel mill production challenges¹ in Poland & Russia at the turn of the 20th century.

What was the problem that the Harmonogram solved? Adamiecki’s job at that time was investigating plate steel mill production. Attempting to improve productivity. His observations led him to believe there were opportunities for improvement, but his initial attempts to implement these ideas were met with resistance from the work force. Being seen as an outsider with limited knowledge of that specific factory would cloud the openness to change. He needed a tool to help him communicate his observations and illustrate how change could lead to improved productivity. At that time there was no apparent right tool for the job. So, he invented one. The Harmonogram.

Creating a graphical representation of work activity, duration and relation to other operations he was able to illustrate where time and productivity was lost. This new tool, enable him to gain the influence necessary to implement changes, not just at his primary factory but also in Russia.

In the Western world, Henry Gantt is credited with the invention of this graphical tool. But both men developed their initial solutions from steel and manufacturing backgrounds. With the demonstrated success in the factory, taking their management principals and charts to other forms of industry was a natural next step. The idea of integrating activities and illustrating them graphically wasn’t only constrained to the manufacturing floors. For Gantt, transitioning from manufacturing to project management in the 1920’s was a deliberate attempt to address complex multi-functional projects.

Beyond giving credit to other inventors of this visual method. This story tells how the inventor came to understand the problems they were facing and created tools to help achieve their objectives. Whether it is waterfall diagrams, Kanban boards, Stand up meetings. Leaders are faced with communicating and coordinating across domains to drive action. Working with the teams and understanding the needs and the problems enables a wise leader to apply the right tool to the right job.

I have my preferences in tools that I will default to when initiating a project. I also work with the teams to learn what will work and how best to apply the tools we have at hand. Software development using scrum or agile doesn’t easily transition to Electrical or Mechanical project management. And when all disciplines are involved in a project finding a way to tie them together in hybrid approaches can be the most effective. The Project leader should be seeking tools to influence and focus the tasks at hand to deliver the highest quality results with the least cost and time duration.

1. Bart J. Debicki , (2015),”Forgotten contributions to scientific management: work and ideas of Karol Adamiecki”, Journal of Management History, Vol. 21 Iss 1 pp. 40 – 67

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.

What is Project Fog? An Example…

Things that might make project uncertain and create a fog for the team. Inhibiting early progress.
An ERP project I worked on had a desired go live date. As the team assembled each team member made assumptions of what modules would be part of go live and what go be added in future dates. If this is not caught early enough in the process teams will begin working with consultants on configurations without sound coordination. Unnecessary work get started consuming resources and or other configurations would have to be reworked.
It’s a simple example of team uncertainty and clarity in requirements can create fog.

A product development example; could occur during market introduction. Assumptions about which markets a product would be released to first will drive documentation, SW UI and compliance work. Market dynamics might shift the priorities creating uncertainty in how resources are planned and schedule impacting progress or resource scheduling.

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.