Scope creep. Or, what kind of fries did you want with that?

There are countless reasons why a project can spin out of control. In my experience the single biggest reason is scope creep.

From Wikipedia:

Scope creep

From Wikipedia, the free encyclopedia

Scope creep (also called focus creep, requirement creep, feature creep, function creep) in project management refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence, and thus, should be avoided.

Typically, the scope increase consists of either new products or new features of already approved product designs, without corresponding increases in resources, schedule, or budget. As a result, the project team risks drifting away from its original purpose and scope into unplanned additions. As the scope of a project grows, more tasks must be completed within the budget and schedule originally designed for a smaller set of tasks. Thus, scope creep can result in a project team overrunning its original budget and schedule.

If the budget and schedule are increased along with the scope, the change is usually considered an acceptable addition to the project, and the term “scope creep” is not used.

Scope creep can be a result of:

Scope creep is a risk in most projects. Most megaprojects fall victim to scope creep (see Megaprojects and risk).^[citation needed^] Scope creep often results in cost overrun. A value for free strategy is difficult to counteract and remains a difficult challenge for even the most experienced project managers.

It is extremely difficult to avoid on major projects and doesn’t take much to create havoc within any given set of processes.

The use of established project techniques will not ensure avoiding the situation. Not without agreement from clients, top management and team leaders. Even with this agreement one can see aspects of scope creep balloon out of control.

Certain types of projects are more susceptible to this phenomenon than others. Large projects like AAA games, Feature films or any project that will rely on revenue gains after the fact are probably the biggest at risk. But in these cases, if well defined, scope creep can be seen as acceptable along as resources are applied to accommodate them. Then they no longer get called scope creep.

Projects that have a set max budget or schedule are the ones that suffer the most and where the death march comes into its own. Not to say that ones that can have resources adjusted will avoid the death march but they can be made to be shorter. Risk versus reward can play a big role here.

An example of scope creep that I was recently involved with was a major animated series, (I know it isn’t a game but the same rules apply!),  that I was brought in to help reach the contractual deadlines for.

It had been in production for about 4 months by the time I came on board. In that time the project scope had changed so rapidly and by so much that no one knew exactly how far off the path they had gone. They only knew that they were in serious trouble. It was originally an 8 million budget and had a crew of around 160 for all departments, from writing to final post and delivery to networks.

My first task was to get an idea of what each department was supposed to be doing as per the project guidelines. I went from team to team to get the information directly from them as to what they felt they should be doing as opposed to what they felt they were actually doing and comparing that to the overall guidelines, contract and delivery specs that had been agreed upon by the clients, creator and owners of the various companies involved. I also needed to see details on schedules, budgets, cost reports and try and figure out where exactly the cost over runs were taking place and why.

It quickly became obvious that there was a large disconnect of expectations between the Creator (who had the final say on shows) and the teams that were involved in doing the creation of the work. This disconnect was back and forth over areas like a misunderstanding of content creation and execution as well as the overall expectations of what was to be delivered. It was a situation where no one individual could be blamed (although attempts were made) for the overall cost over runs.

At this point I felt I had to make everyone aware that finger pointing wasn’t going to help. We went directly to the end client to negotiate what their minimum expectations were based on the original contract and versus what had been done so far and what could be done with the money and time that was left.

Part of the negotiation with the end clients was the absolute deadline for each episode. This was complicated by what is known as a production bond. This is a sort of insurance that companies pay for that attempts to protect all parties involved and ensure delivery of product. The last thing a producer wants is for the bond to get called, as the producer will likely lose all control of the product and any potential earnings. The bond company may, at their discretion, bring in another company to complete the work.  Typically the window between the contractual delivery dates and the bonded guaranteed dates are 60 days. So if your first delivery was for May 1, you have till July 1 to get your act together and deliver. Sounds simple enough doesn’t it? It was at this point that it was discovered that if we continued with the processes and agreed to expectations, we would be at least 90 days off the delivery dates.

So what does one do?

First thought is to run as far away as you can. After getting out of breath and having to stop at the local coffee shop, you sit and try to boil the problem down to its essential components. Each project will be different for sure but this is a good exercise to do when you are panicking.

So you have expectations of end client + original design agreements + what has been actually done+ budget and schedule – how much time and money you have left. I am sure I am forgetting something so feel free to add.

In this particular case there were a few extreme decisions I felt had to be made.

The first was the original expectations of content had become firm.

Then the process in the creation of that content had to change radically in order to meet the budget and schedule.

This meant two things. First was a constant negotiation with the content owners as to what were the minimum requirements. This is tricky as any creative process can have a certain level of ambiguity.

Secondly the pipeline had to be completely rebuilt and simplified wthout sacraficing quality. Sadly this meant having to reduce staff. What I wanted to avoid was in reducing staff, not increasing the amount of work for each of those that were left. Sometimes it worked and sometimes it didn’t. There were departments that had to work much harder than others but I tried to have incentives reflect that. They couldn’t be financial at this point. More morale building than anything and were things like trophies for most hours without retakes or best scene completed in the shortest period of time.

To keep it short(er) the project ended up delivering on time (within the 60 day limit) and the end clients were happy. The crew was exhausted and was glad it was over. After 12 and a half months and more hours than I am willing to admit, I took three months off and swore I would never do something like that again. At least not till the next time.  

The original creators and content owners were unhappy and I suspect will shank me in a dark alley someday.

Oh well, that is the life of a project manager.

If you ever find yourself in a situation where scope creep is out of control just ask, what sort of fries are they really willing to live with.