Fling Media

Thursday, March 22, 2007

The Project Chain

Regardless of the size or experience of your team, projects always run the risk of going bad. At Blue Flavor, we’ve come to the realization that you never remove this risk entirely. If one thing in life is certain, things can always go wrong. But we have found a process that reduces risk, distributes work, strengthens teams and allows us to snap back quickly when external forces push against us. We call it the Project Chain.

If you are like me, trying to understand formal project management methodology can be like reading Foucault’s Pendulum, you get what is going on, but it makes your head hurt. While the principles are always great, adapting to them to your team and your project and an entirely different manner.

Add to this that managing interactive projects like a website redesign or a web application don’t fall into the typical models of project management. They are part creative and part software. Once you add subjective opinion, behavioral and psychological variables that typically impact the course of an interactive project, we web practitioners are left few resources to successfully models to manage our projects.

The Project Chain is a process that we didn’t sit down and write, but organically evolved (and keeps evolving) at Blue Flavor. To be clear, we don’t believe in dedicated project managers. Everyone at Blue Flavor is responsible for managing their segment of work, placing experts in direct contact with our clients, reducing middlemen, back and forth and ultimately time and money. Each of us take share the responsibility of managing the overall project, but it is highly focused on managing schedule and budget.

As this agile and segmented approach evolved, the concept of the Project Chain was born.

The Chain Metaphor

Now when I say chain, you probably visualize thick and strong iron chains, an impenetrable method of restraint. Wherever I hear the word chain associated with a project, what always pops into my head is the scene in the original 1933 King Kong movie where the giant ape is being held back from the crowd. It always seemed like a fitting metaphor, as I envisioned me being that guy in the front row, wondering if those chains will hold the titan project at our whim when… snap! roar! squish!

No, the chain I refer to is more like a bicycle chain. A series of many small segments linked together to create a flexible, but incredibly strong method of moving large objects quickly. It might look something like this:

For those of you who haven’t been on a bicycle since your first trike, or maybe the closest you get to one is by watching the Tour de France (viva la Tour!), the bicycle chain is an odd thing to hold in your hand. It moves like a snake, rippling in nice, even, fluid waves, but only in one direction. It never wavers from side to side, it cannot by twisted or contorted easily.

Yes, moving cogs, sprockets and wheels are far more fitting metaphors for process and projects than the shackles preventing the impending onslaught of a gargantuan beast. We can use this as a basis of a process for corralling and moving projects rather than forcing them to our will.

The Power of an Org Chart

In the must-read book about small business, The E-Myth by Michael Gerber, Gerber recommends creating an organization chart regardless of the size of your company, defining each of the roles in your business.

Even if your company is just a few people, you must define the roles or hats you will wear, separating each person into the role(s) they need to play. For smaller teams you will find the same names in many boxes, but you will be able to better visualize the needs of your company and where resources are constrained. For larger teams you will better define the hierarchy and expectations, taking out confusion and guesswork.

Without an organization chart, everything hinges on luck and good feelings, on the personalities of the people and the goodwill they share.

These same principles apply to projects just as much as they do companies. Projects are exactly like small businesses. At its core, a project is just an organization of people that share a common goal. They share many of the same risks and challenges. The only exception is the company’s goal is longevity, like a circle, whereas a project is finite, like a straight line.

Creating the Chain

Enter our chain. Using the metaphor of small interconnected segments of project functions, we can provide labels and names to each to describe our process. When formed together, they work like a conveyer belt moving projects from the beginning to end.

Like the E-Myth Org Chart, place names into each of the segments of the chain, even if that means some names are in multiple roles spread out along the chain. Assign one person as the leader of each segment, the person that will set internal expectations, make key decisions and be the go-to person when problems crop up.

Remember that no segment works independently. Each is connected to at least one other segment, creating crossover and collaboration among team members. This interdependency is an important principle of the Project Chain—not in a condescending, we’re-telling-you-to-do-it-this-way way, but rather from years of observation of how projects organically work.

If one segment hits a road block or is faced with new challenges, it creates a curve in the chain that ultimately effects the entire team. These curves naturally happen, that cloud of black doom that hovers over all projects. By working on the project as a group of highly interconnected segments, when bad things happen the entire team rises to the challenge, getting work done faster, better, cheaper and bonding the team together in the process.

Being Flexible

With all this talk of chains, structure and process, it is important not to forget that successful projects absolutely depend on the ability to be flexible. At Blue Flavor, we pride ourselves on never applying a canned process to our work—no two projects are exactly alike and we take different approaches to each. The Project Chain works perfectly for this.

Being an agency, we are fortunate to have our company organized pretty similarly to how we assign ourselves to projects. Therefore, we have a Master Project Chain that isn’t applied to a project, but rather the company—the conveyor belt we use as a template for future projects.

For each new project, we use our template to create a Project Chain specific to the client. Adding or removing segments, or entirely redefining it based on the clients needs. The project team usually changes slightly from project to project, meaning that everyone takes a turn participating or leading a segment, matching skills and experience to the clients needs.

Having spent the majority of my career leading internal teams, I can say that this same approach works well with internal teams just as much as it does agencies. Although, the risk is that it is far too easy to apply the company org chart (like the E-Myth one you might have) to your project chain. For example, unless you are a company of ten people or less, you should rarely see a CEO, COO, Vice President in your Project Chain. Your chain should represent how you functionally work, not how executives think.

Curves in the Chain

Projects can have a tendency to move like a tsunami, creating a steep and sudden wall of work followed by a long sloping arc back to normalacy. As the project moves through each function or discipline, resources are literally handed work with little-to-no context, producing a sharp learning curve and ramp up time, having never participated in early phase planning or discovery. This is wasteful of time, money and resources.

It is important to not view projects in a purely linear, one-directional fashion. It is easy to assume that once you’ve completed your task, your work is done. It is this lack of foresight which creates the tsunami in the first place. The more people that fail to participate in the fluctuations of the project, the larger the tsunami wave gets.

With the Project Chain, as complexity increases in one segment or function, it increases complexity in the interconnected segments as well. For example, if the design of a website suddenly gets more complex with some unforeseen problems, the peak in the chain increases the complexity of the connected segments. Depending on the level of increase, it may send a ripple effect to the Information Architecture and Development segments as well.

In the Project Chain, the entire team works as a single unit. Your responsibility to the team is not complete until the project is over. Even though you might have completed your work months ago, that doesn’t mean that you can write it off entirely. If work increases in one segment, the team may call on you to provide your expertise once again to help solve these new problems.

Conclusion

Now before you get too excited thinking that the Project Chain will solve all your project management problems, understand that process should never be adopted, it should be adapted.

Start with the high level, how does the work break down into functional segments? What are the desired outcomes of each segment? What are the expectations you have for each segment? What are the expectations your clients or stakeholders have? What are the artifacts you are going to produce with each segment? Then ask: are you missing any segments? Do new segments need to be called out in your chain?

When your chain segments are mapped out, then start defining roles and responsibilities. Only once this is done assign the people on your project to each segment. It is too easy to put a name in a box and funnel work in their direction based on their job title. This never sets anyone up for success.

Instead constantly set expectations with your team, be flexible and have some fun.

---