Outsourcing

Keep IT consulting project scope small for success

Negativity can kill a project, but the opposite is also true: You can stuff a project with so many features that it's crushed by its own weight.

A common objection to a project plan is that it doesn't do enough -- it doesn't have all the features that users will inevitably request, or it doesn't take certain situations into account. Or as TechRepublic member biancaluna recently put it, it "...does not solve world hunger nor does it wash my car or bake a pecan pie." But in my experience, those omissions argue for it rather than against it. Certainly, you don't want to preclude features that will be needed in the future, but if you try to anticipate all of those features in the initial design, you'll never complete that phase. Rather than designing in everything from the top, start small but make your design modular and extensible.

In my response to biancaluna's comment I said: "In the future, whenever someone tries to shoot down an idea because it doesn't do enough, I'll say 'DNSWH.'" Does Not Solve World Hunger. It's also a good response when someone is trying to pile on the features.

A company I used to work for had a long history of cowboy coding -- that is, "we need feature X, so just go code it up." Naturally, after several years, this resulted in an unmaintainable mess; they got design religion and began requiring a lengthy design process before any code could be written. To insure that nothing important was ever left out, they held daily design meetings involving a dozen or more people -- each of whom was trying to impress everyone else with how many nits they could pick. Only a handful of projects ever emerged from this phase after months of bickering, and those projects went on to become bloated applications with so much feature noise that they were almost unusable. What's even worse is that the projects didn't solve the original problem, which was to keep existing customers happy and to draw new customers in; instead, they focused on solving world hunger.

A number of times in my consulting career I've had clients want to ditch their product and start over from scratch. Perhaps the UI looks "old" and needs to be redone; or the code is so mangled that they think it is beyond hope; or they've hired someone who thinks that a certain language or framework is the philosopher's stone that will magically turn their applications to gold. These projects almost never succeed. Why? Because they're too big. Yes, you can certainly recreate that application in Ruby on Rails in a fraction of the time spent on it to date, but do you realize how much time has actually gone into it? Chances are it's in the hundreds of thousands or even millions of hours. Even if you can develop ten times faster than the original, do you have several years to do this?

Sometimes it's easy to mistake how big these projects really are because their requirements aren't fully known. The projects have evolved over many years, and features are sometimes added without being documented; yet users rely on that behavior, and if you take it away, you're going to end up pasting it back in. Do that enough times, and your new, pristine version will end up being the same mix of baling wire and bubblegum that comprised the original.

It's almost always a better idea to make incremental improvements instead. That requires long-term vision of where you want to get someday, without trying to do it all at once. Lay out a general plan for the future, and then create a specific project to do just the first step. That helps to minimize the risk of failure and keep the project scope manageable. It's easier to agree on the design for something that does only one thing well -- and it's easier to tell when it doesn't. More importantly, you can get user feedback before you proceed to the next stage.

Trying to do too many things at once multiplies your chances of project failure. One company I worked for back in the 80s provided turnkey solutions -- that is, they wheeled the system in, and all the user had to do was turn the key. The vendor provided the hardware, the operating system, and the software. One bright day, the vendor decided to upgrade their database architecture. To do so, they needed a new version of the programming language and its runtime environment. That version was only supported on certain operating systems, so an OS upgrade would also be required for most users. The applications (mostly accounting) still needed regulatory changes, and they felt that they couldn't go a whole year without adding some enhancements as well. To keep things "simple," they decided to do all this at once -- to more than 1,300 supported users. It would be great -- what could possibly go wrong?

The OS upgrades ran into hardware support issues. The language runtime was still pretty green on some platforms and introduced a massive number of failures -- none of which showed up in QA, of course. But certainly a redesign of the database architecture should have been a simple task, right? No. Application bugs abounded due to touching just about every module.

The support lines were overwhelmed. Extra people manned the phones, including all the programmers. As a result, it took a long time to fix the issues. Meanwhile, we'd go home at night only after we attempted to call back every customer who had logged a call, but by then it was so late that they had given up on us -- this added up to more than 700 users every night for months. Did we keep all of our customers? No. Did we add any new ones? No, we tried to solve world hunger instead.

In retrospect, we should have taken on only one thing at a time. Upgrade the language runtime on one platform only where we already had users who wouldn't need an OS upgrade. Don't touch the database or the code until that's stable. Continue one platform at a time until the new runtime version is gold. Then look at changing the database -- but only a portion of an application at a time. Taking this sort of measured approach, we would have been able to slip in regulatory changes and even some small enhancements along the way, without breaking the customer's back.

For us consultants, limited scope is one of the key benefits of short-term contracts. In, done, out. But we can apply the same principle to long-term engagements as well by dividing each project into bite-sized chunks. When a project looms massively before you, ask how you can cut it up so you won't choke on it. Identify the optional features and move those to the end, where they can be lopped off if you run short. Don't try to solve world hunger -- feed one user need at a time.

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

26 comments
Sibleyhaley
Sibleyhaley

Hi , Thanks for writing such an interesting article. It is not easy to take the right employee especially if we don?t have great human resource division inside our company. Special division of human resource usually required but some companies think that is not necessary thing. Trianz is a client-oriented organization that provides an integrated set of Consulting, IT and BPO solutions, each enabled by innovative and proprietary global execution models. Trianz firmly believes that the flawless execution of business, technology and operational initiatives is a key ingredient of business success. Their mission is to partner with business leaders, who share the belief that Execution Matters. They understand top management vision and objectives, visualize business results and translate these to the execution of strategy using relevant technology and process outsourcing. Thanks, - Sibley

rhowelljr
rhowelljr

Hey Chip, I think we've been down a lot of the same roads. I've done a lot of 'small' consulting jobs over the years. I call it programming for food. I've learned that you've got to keep things contained - finish one thing and move on to the next. Make sure you don't paint yourself into a corner. You can always extend a stable and modular project.

snaptechguy
snaptechguy

This was a post worth reading! Glad I stumbled across it. Another interesting site I came across was this: http://www.snapTech.co.za. Take some time and check it out. I will definitely visit again soon. Keep the awesome posts flowing.

maryclaire.salander
maryclaire.salander

Thanks for an interesting and well-written article. I would offer up for discussion that many project proposers are really trying (with good intentions) to provide a solution to a business problem that they have not articulated. In my book, it's the job of the requestor to document and present a business need and the job of the solution provider to analyze the need, design the solution, validate that it addresses the stated need, and then go for it.

mddawdy
mddawdy

When you consider the fact that over 70% of IT projects (also construction and other project types) fail, your observations Chip are right on. Of course, it sort of sounds like "Agile" or "Scrum" project management and it works similar to an over all large project broken into much smaller and more manageable chunks. The good news is that the owner or stakeholders - who often do not know exactly what they want - can have their needs met better with the smaller success idea also, because when the adjustments come, they can moved into the next "chunk" smaller project - if, they merit the scrutiny of the approving board/committee/team. Good Article, thanks.

PMPsicle
PMPsicle

The first is scope control. When my kids were young (they still are) we called this the "I wann" effect. As in "I wan a toy", "I wan a hossie" etc. One of the things a project manager needs to do is qualify the "I wanna"s. And if it's not in the original agreement go back to the sponsor with a cost and effect. The second is my problem with the concept of seperating program and project management. One of the realities is that an overloaded project is an unfinished project. Short and sweet gets done. Long and complex needs to be broken into sub-projects. As a WBS (and requirements) are broken down into smaller parts sub-projects will appear. By managing each sub-project independently (aka as a phase) you reduce risk, improve variance and improve control. That's actually one of the keystones of Agile (Critical Chain) project management. Of course, if management gains a reputation of never doing the second phase you as a PM are SOL. The third is risk and complexity. The more complex the task the greater the risk and the effect especially on the threat side. In fact, the opportunity side of risk & effect is often reduced as complexity increases. So to summarize, you're right on the money Chip. KISS even if you have to return multiple times BUT don't lose sight of the overall level of complexity. Glen Ford, PMP http://www.trainingnow.ca

mars_am
mars_am

"Small" is misleading. Every project has a budget and a time horizon. If the development and features fit within that, then "go for it". Otherwise, cut out the extra stuff. And if the project turns into a "complex system", then bring this to the customers' attention with options on how to handle this. World hunger as a project is solveable. It needs to be chunked into manageable pieces, and those pieces should be part of a framework that has the desired end result. Problem is, no one really knows what the end result should be. I suggest that "small" equates to "limited horizon" in this type of scenario.

pwoodctfl
pwoodctfl

Setting appropriate expectations is the problem for almost all projects and keeping an eye on what we are trying to achieve. A good tester can help with that (shameless plug for my profession). But the incremental approach can be equally deadly....I will call it the Christmas Tree effect...where a basically good product was "improved" to death....hanging one piece of functionality after another on the frail infrastructure until the effect is pretty, but unbelievably dangerous and unstable. I think the cure for both problems is an honest conversation with the client.....do they really need a single application that can wash thier car, feed the cat and turn back global warming? They would like it of course....but do they need it? Would they recognize it if they had it? Do they even own a cat? Embedding a tester in the design team can provide an annoying voice that keeps asking the stupid question...And when would you use that? And how do you do that now? And how often do you do that? And how would you know that you need to do that? These simple questions help focus the development effort to produce what the client needs....not what just what he thinks he wants.

Bebedo
Bebedo

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." ? Antoine de Saint-Exup?ry

Sterling chip Camden
Sterling chip Camden

I'm sure you have lots of examples of when scope got out of hand and resulted in a project that never ended (or had to be kill -9'd).

Sterling chip Camden
Sterling chip Camden

I learned the principle even before I went into consulting. If you can segment projects into achievable chunks, then you can manage the long-term schedule better. You can drop the parts that are optional and which you left "until later" -- but only if the more important parts aren't dependent on those bits. Separating the dependencies is the key.

biancaluna
biancaluna

In my experience, and I have been doing this for almost 2 decades, the lack of knowledge about the business is a major issue for the business :). See, many business divisions don't have a big picture view, at times they don't have a clue what they do or what they need. Even some large IT outsourcing companies I worked for in the past, had limited understanding here (touches heart) and here (touches head) about what it is they actually did and could not articulate that very well. I work in Govt and semi govt organisations a lot, consulting is a black art in these environments as these types of organisations do not view themselves as a business. what you propose is the ideal situation, that is hardly ever reality. As a consultant, I look for similarities in processes and validate those with the business when a project commences, we do need to help the business with the right questions. That is experience, not scope definition.

Sterling chip Camden
Sterling chip Camden

I specifically avoided the term "agile" in this article in order to discuss practice over theory -- but yes, this is one feature of the Agile approach. Thanks for your kind comment.

Sterling chip Camden
Sterling chip Camden

In my experience the trouble has been that management thinks it all needs to get done in one iteration or it will be too late. But when you pack everything into one iteration, it ends up getting done wrong, which costs even more time in the long run.

Sterling chip Camden
Sterling chip Camden

... when the budget and time horizon get too large, the project can easily lose its way. It needs to be divided up to stay in focus.

Sterling chip Camden
Sterling chip Camden

Test Driven Development. I'm a believer. Create the tests before you create the feature -- it really helps make the implementation solid. But yes, I do believe in involving testers in the design phase. They inevitably find something...

Sterling chip Camden
Sterling chip Camden

Even quite successful businesses often have no clue about what makes them successful, and they can easily destroy it by trying to do something else. But maryclaire's advice is still right on. One of our jobs as consultants is to clarify the client's vision about their business. Then and only then can we tie project proposals to real business needs.

biancaluna
biancaluna

Well there you go, my name in lights. Mum would be proud. I had to think back to my first PM mentor, many moons ago. He always told me that schedule horizons of more than 6 months are innately doomed to fail and also to keep milestones short, 2 weeks max. So that you had achievements that were ticked off one by one. We haven't addressed an important problem with scope creep and the all encompassing DNSWH scope and that is failing business processes. I am still trying to close the project that made me utter those words, partly due to the indecision by committee exercised in the org. Partly because the expectation has been (the unspoken but everybody knows kind) that what I was putting in place would resolve business process failures. I have not seen a lot of technology that can resolve business process failures of the Layer 8 type (human beings in the ISO reference model). We have twisted ourselves into lots of turns to be able to catch the gaps, and plug the holes and resolve issues with the technology caused by people not complying to agreed business processes. garbage in, garbage out, technology fails, technology is changed, still fails, etcetera etcetera. Requirements definition is paramount as are the cojones of management to lay down the law and make organisations responsible for their part of the system. Unfortunately, as a PM I am also expected to be the BA, the technical writer, the facilitator and the tester. Small project in dollars, big scope in impact.

PMPsicle
PMPsicle

Typically, this is their (management's)own fault. They frequently feel this way because there is a tradition of only doing the first phase and then letting the latter phases die. What they forget is the tradition exists because management took the project team off the project after phase 1 to do another priority project. But since they're management now ...

Sterling chip Camden
Sterling chip Camden

cross, wooden stake, and silver bullets. Of course, we all know that the latter don't exist.

biancaluna
biancaluna

Of course. Which is why I always start the day with a short prayer and cry session :). The tools of the trade.

Sterling chip Camden
Sterling chip Camden

If there is any supernatural influence in our business, it comes from the other direction.

santeewelding
santeewelding

Has to be where your past theological ruminations come into play!

biancaluna
biancaluna

The procedures were put in place with agreement from this organisation and are in line with privacy legislation and security policies for system access. They are blatantly changed to the point the organisation is in breach. Pure laziness and empire building and not towing the company line.

Sterling chip Camden
Sterling chip Camden

The process is failing because people aren't following the procedures? Maybe the procedures need to be adjusted to fit the humans. Put the sidewalks where the footpaths have been made in the grass. Just a thought.

Editor's Picks