Scope Creep or My Beef with non-IT Project Managers Complicating IT Projects

Scope Creep.

Some would argue that it is an inevitability in the world of IT projects, especially those in the software and web development realms.  To a large part, it is.  Oft times, even with requirements documents in place prior to the start of work, as a project moves along its development path, the customer realizes there is something they forgot to list as a requirement or looking at the prototype spawns a thought or they see something that would be “really cool” to add to their product.  Many times, as well, the developers don’t mind accommodating the customer.  It shows good faith and intent to provide the customer a product that more than just meets the requirements -it makes them happy.  But if the customer continues to make requests for changes or additions after the project is underway, scope creep becomes a problem.  At some point, scope creep makes reaching deadlines impossible so the developer has to either tell the customer that the “new” request can’t be included or that the time line has to be pushed back -neither of which makes for a happy customer, unless they are one of the few rational ones who understand they have caused the situation.

Now, throw a poor, non-IT “project manager” into the mix and you’ve got the makings of a disaster.  The project manager doesn’t have a clue how long any of the development really takes or how closely the project already is to meeting the deadline so they keep promising the world.  Meanwhile, the developers are wondering how to find new jobs before the ship goes under.  They hear the band playing, but can feel the deck accelerating to 90 degrees and they don’t want the reputations to go under with the project.

Another problem with non-IT project managers is that they think they can just throw more money at the project to speed it up.  Buying off-the-shelf software/plug-ins for the developers works great, but can only go so far.  The developers still have to code to make all the other drop-in widgets/software work with each other and the rest of the product.  The other thing these managers like to believe is that they can simply throw more bodies at the development team to get it coded faster.  Depending on the size of the project, this is true, but even large projects will hit a point where they are saturated and more developers will just begin to crowd the workspace.  Unless there are blocks/pieces/sections of the project that can be split out to multiple developers, adding more developers to work on the same piece of code won’t speed things up.  To quote my boss, “9 women can’t make a baby in a month.”

Don’t get me wrong, there are project managers with IT backgrounds who also hose their development teams.  The biggest difference is that when approached by the development team and told scope creep has to stop and why, most IT savvy managers understand and will relate that to the customer or know to ask if additional team members can actually help.

Lastly, project managers, with or without IT backgrounds, that are afraid/unwilling to ask the customer exactly what they want should be lined up and summarily executed, because they are the death of development teams, the bane of their existence.  For some reason, there are too many project managers who think they know what the customer wants because they heard them customer utter a buzzword once, or simply woke one morning with divine guidance.  I don’t know.  I do know that this leads to a disheartened development team –one shooting resumes out faster than roaches scatter when the light flicks on because there’s nothing worse than having to completely overhaul a project because the yahoo in charge failed to ask the customer what they want.


4 Responses

  1. The good folks at PMI say that change is inevitable, which mandates a change control process.

    The thinking goes, that a good (and adhered to) process can go a long way towards managing scope. I guess I buy that.

    • I agree that change is (almost) inevitable. The problem is more in the area of expectation management. If the customer is given a timetable for completion, and they ask for a change, they have to understand that THEY are also forcing a change in the timetable. Most of the time, a change early on is easier to deal with, as well. Further on, a change request can force a major overhaul of the back-end in order to make the “small” change possible. Non-IT PMs will often not understand this and set a new time line without giving their development team a fair chance to evaluate the true scope of the change.

  2. Be happy with scope creep…at least you have a job.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: