Puzzling Over Projects

In the first course I took in Microsoft Project, back in 1997, we spent 2 days working on a case study that consisted of just 12 tasks that were all in sequence. A pretty little waterfall chart that left me puzzled. Over the years I’ve heard the word ‘project’ used to define a great many things, many of which were not actually projects. Twelve tasks in sequence definitely falls into the latter group.

For example, a couple of years ago, I met a contractor that specializes in building high end, residential housing. I asked him, ‘do you consider each of those houses’ to be a project? His answer, was somewhat surprising. He said, ‘no, not really’. He went on to explain, they build a lot of houses, each one is almost like a production process. Then I asked, ‘well, what do you consider a project?’

His answer was revealing, he shared that a project for him is building a whole sub-division. They have to find the plot of land, get the financing in place, permits from City Hall, arrange for infrastructure such as water, sewage and power, design the lot layouts, road access, coordinating the housing designs with architects and the marketing. That is a project!

This example focuses on a combination of two key variables when defining a project:

– How complex is the body of work involved? This is usually defined by the ‘deliverables’ and how many tasks involved to create them.

– How novel this endeavor is compared to our ‘normal’ day to day work? For example, building the prototype of a brand new product, is very different from manufacturing ‘X’ numbers of those products day in and day out.

There are lots of definitions of projects, all slightly different. One of the more common is:

‘something that is contemplated, devised, or planned; a plan or planned undertaking:’

The key takeaway here is that a project is so complex that it requires a plan to figure it all out.

The creation of deliverables in a project, regardless of complexity, requires a combination of inter-related tasks. They are too complicated to be presented by conventional means. The coordination of those tasks is created with an ‘Execution Plan’ which is made up of:

– a visual diagram of the workflow
– a catalogue of associated data, including logical relationships, resources and funds.

The complexity of the coordination increases exponentially the more ‘pieces of the jigsaw puzzle’ there are.

Gray Castle

The analogy between Puzzles and Projects has been around for a long time. Bear with me for a moment as we take a closer look.

The picture on the puzzle box represents the idea or the final solution of both puzzles and projects. Some call this the ‘design’, a term getting a lot of use these days.. The design may be so complex it requires its own planning process to create the picture. This applies to any type of project result, whether it is physical in nature, like this castle, or software or processes, a charitable fund-raising campaign, etc.

The point to remember is that a project requires two types of planning: figuring out, and agreeing on, what we’re going to build or create, or change and then figuring out how we’re going to create that deliverable in the most efficient way possible with resources and funds that are available. Some of the worst arguments and misunderstandings happen when one party is thinking about the ‘what’ and the other party is trying to figure out the ‘how’. This is a key factor in achieving project coordination.

Notice with our puzzle, the first thing we do is take a hard look at the picture. And we constantly refer to it to keep us on track during the construction. Can you imagine what challenges we face if the picture was blurry, or incomplete? Or if one of our team members is adamant that we’re building a motor home instead of a castle? What if you were able to create a step-by-step description of how to assemble all of those pieces to assure that the picture is crystal clear to everyone?.

So let’s dump the puzzle contents out on the table. Just like a project, we’re staring at what I call the ‘blob’… the mountain of components (tasks) needed to create the deliverable… in absolutely no particular order. It can be overwhelming. Do you notice something interesting? Not all the individual pieces are facing directly at you. Many are upside down, hiding most of its detail. Not only that, with several different team members looking at the ‘blob’ from different directions, each person will have a different perspective of the work that needs to be coordinated. That sounds like the real world of projects, doesn’t it?

puzzle mound

And there’s nothing worse than finding pieces missing. In a project they have a couple of interesting terms for this: “errors and omissions” and “re-work”. Polite words for those ‘oh sugar’ moments 😉

one missing puzzle piece

Let’s take a closer look at the individual puzzle pieces, or ‘tasks’. Each of those pieces requires a collection of ‘tabs’ and ‘blanks’. These connections allow us to join the various pieces in a coordinated way.

diagram of puzzle pieces

The tasks in a project have similar elements. Each puzzle piece requires its own set of tabs and blanks. Each project task has its own preceding tasks and succeeding tasks connected by links or dependencies.

Imagine for a moment if you opened up the puzzle only to discover, through a manufacturing defect, that all of the tabs and blanks were missing from say a quarter of all the pieces. What challenges would you face?

Imagine the same scenario on a project assigned to you. Most of the easy links were identified, yet a sizeable number of tasks had no dependencies identified. Imagine the challenge you and your team would face in trying to coordinate the plan and schedule without all the links. Or worse still, what if some of the existing links connected the wrong tasks to each other?

diagram of puzzle pieces

A common, 2-dimensional puzzle lays on a flat surface. You could start working on it from any one of the various pieces if you wanted. Some people go for the corner pieces first, followed by the straight edged pieces that form the border. The advantage here is that the ‘scope’ of the puzzle and project are clearly defined. Here’s what’s ‘in’ and here’s what’s ‘out’.

The scope is made up of large components, or deliverables. In our castle puzzle seen here, there’s the land, water, sky, moat, wall, the keep along with turrets and spires.

You can have one, or several people working on the puzzle at the same time. But not so many that you trip over each other! Some like to focus on one deliverable at a time. They sort through the ‘blob’ trying to find all the pieces that have similar properties like colour, or shapes, or even blanks and tabs.

However, you don’t have to do all that, because you can build a puzzle any way you want, because it’s flat. Coordination is helpful, but it’s not mandatory.

In the early stages of a project, when the solution is being designed and sorted out, it is often worked on in a 2-dimensional perspective. Especially when the solution requires research, development, trial and error. Often it is a very iterative process. The development of software, at least in the early to mid-stages, thrives in this type of environment.

diagram of puzzle pieces

However, here’s where the similarities between puzzles and projects start to go their separate ways. What if the puzzle is 3-dimensional? That changes things a lot with the coordination becoming compulsory. You can’t erect the turrets and spires and fly the flags until you build the keep, and you can’t build the keep without having the foundation in place.

Projects are a lot harder to build than a jigsaw puzzle but you already knew that.

castle

Some projects are ‘physical’, like this castle and others are not, like software and process improvement. A physical project has height, width, and depth – physical volume and attributes.

Software has different attributes – hardware, servers and internet, user experience and user interface, security requirements and many more.

The one dimension all projects have in common, is the dimension of time. Time is the one constant. Each day we receive 24 hours of the stuff, no matter who we are. We can’t speed it up or slow it down, we can’t store it up for future use, we can’t borrow it and buy more of it. On the other hand, we might be able to add more resources to speed something along, but there is that nasty ‘Law of diminishing returns’ to contend with.

The larger the project, the more tasks there are, the more time and effort required. The coordination between those tasks is crucial to a successful delivery.

Consider for a moment a large project of say, 1000 tasks.

– Each task requires a description, an ID#, duration, resources, costs, and the links to its respective predecessors and successors.

– For 1000 tasks, we’re dealing with approximately 8,000 to 10,000 pieces of data, each piece of data has to be accurately curated and coordinated to form a coherent relationship with all the other data points.

– Errors and omissions will cause re-work. Finding and correcting them inside the plan is infinitely less expensive in time and money than finding them on the job site.

I’ll leave you with this final thought. A few years ago, I had the opportunity to talk to a subcontractor about the frustrations he encountered in projects. This is how he summed it up:

“I’m so fed up arriving at a job site, only to have to explain to the site supervisor that I can’t install this piece of equipment until the walls of the building are erected first.”

The intent of this article is to bring some clarity to a complex subject. Please share your thoughts and comments below. If you have any further questions, don’t hesitate to send me an email.

OVERGantt will help you define and manage your projects better, if you want any more information,
then get in touch with us today.

Article by Alan Uren