Developer

10 classic mistakes that plague software development projects

When you combine project management pitfalls with software development challenges, you have a recipe for some big (but often preventable) problems.

Project management is never an exact science, but when you combine it with the vagaries of software development, you have a recipe for disaster. I have seen a fair number of common mistakes that project managers make when working with software development projects. Some of these mistakes are not exclusive to software development, but they are especially prevalent and damaging in that context.

1: The "pregnant woman" mistake

Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again -- the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true.

Every person you add to a project adds friction to the project as well --  things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just can't be split up to be done by many people or teams at once. They simply have to be done "one foot in front of the other."

2: The wrong metrics

Managers need metrics for variety of reasons: measuring "success" or status, performance reviews and analysis, and so on. The mistake I see too often is that the easier it is to collect a metric, the more likely that it's not measuring anything useful. Of course, the easiest metrics to collect or understand are also the most likely to be used. Let's take "bug tickets" as an example.

It is easy to count how many tickets get entered. But that is not a good measure of quality, because how many of those tickets are user error or truly "features"? So managers often look to the next level of metric: ticket resolution rate (tickets closed per day or week or iteration or whatever). If you have ever dealt with a help desk that constantly closes tickets for things that aren't actually fixed, causing a proliferation of tickets, you know what it's like dealing with an organization driven by this metric!

Instead of actually getting work done or helping the user (for example, leaving tickets open until the user accepts the resolution), the organization exists solely to open as many tickets as possible and then close them as quickly as possible, so it can get its resolution rate up. A better number would be the hardest to measure: ratio of true "bug tickets" created in relationship to features deployed, changes made, or something similar. Needless to say, that is not an easy number to understand or to collect and report on. The result is that organizations choose to make decisions based on the wrong metrics rather than the right ones, due to convenience.

3: Estimating times too far out

A common problem I see with certain project management methodologies is that they like to play "just so stories" with timelines and time estimates. Project manager who honestly think they know what pieces of functionality any given developer will be working on more than a month or two out (unless it is a very large, broad piece of functionality) are likely to be disappointed and mistaken. Software development is just too unpredictable. Even if you can prevent or account for all the usual things that alter timelines and priorities, there is still little guarantee that things will take the time you think they will.

4: Estimating times too broadly

Another typical issue with time estimates involves not breaking tasks down into small enough pieces. If I'm told that a piece of work will take one week, I'll ask where exactly that number is coming from. Unless someone has analyzed all the minor pieces of work in the whole, a "one-week" time estimate is nothing but pure conjecture and should be disregarded.

5: Failing to account for tasks

How many times have you seen a deadline blown because it was established without accounting for a critical task like testing? That is another reason why you cannot and should not ever accept a task on a timeline that is not broken down into its component tasks. There is a chance that the estimate omits something important.

6: Poor communications

It is important to keep everyone in the loop on project status, but it is easy to forget to do it. This is where a lot of the mistrust between IT and the business team comes from: The business does not feel like it has a good handle on what's happening with its projects. And the more it feels left in the dark, the more likely it is to start trying to micromanage or force things to happen the way it feels it should be done. You can mitigate this problem by letting people know where things stand, both on a regular basis and when milestones are accomplished or the status changes.

7: Disconnected business priorities

There is often a wide gap between the priorities of projects within the development organization, the priority of the project in the view of the overall business, and the priority of the project in the eyes of the requester. A common issue is that a "high priority" project for one department is not viewed as important by the business because it does not generate revenues, and so the developers also downgrade it. Everyone needs to be on the same page with priorities, and a large part of that is to ensure that business units are not evaluated on the basis of projects that the overall business considers lower priority.

8: Constructing a wall of process

When the development team feels overwhelmed, one of the natural reactions is to establish a lot of process to slow things down. I have worked at places where even the most simple of changes required a change request form to be filled out (on paper, of course), in triplicate, physically disseminated, agreed upon, cross-signed by managers, and after all of that, there was still a 45-day minimum time until the work was to be done! Needless to say, this organization was not seen as a "partner" or an "important lever for getting work done" in the business, they were seen as a cost center and treated as such. The wall of process is typically a stopgap measure to deal with deeper issues in the process or company's culture, and while it is easier to put up the wall than to deal with those issues (and in some companies, the issues are irreconcilable), the wall of process is counterproductive and leads to a hostile environment.

9: The "hit-the-ground-running" myth

When adding people to a project, it is tempting to assume that they can hit the ground running. No one hits the ground running in the world of software development, and those who say they do are mistaken. Every project has an acclimation period, and the farther along the project is, the longer that acclimation period is -- there is more and more code to understand and get a handle on. Failing to take this into account will get you into hot water. It may take only a few days or weeks for a developer to come into the project at the beginning, but it could take months for a developer to be fully productive when added to the project long after it has started

10: Multi-tasking

This is another "skill" (like "hitting the ground running") that people think they have, but they really do not. The more you ask people to multi-task, the worse their work will be and the longer it will take. This applies to multi-tasking at the minute-to-minute level (juggling emails, phone calls, actual work, etc.) as well as the hour-to-hour or day-to-day level (handling multiple projects). The more you demand from people, the more the wheels fall off. To make it even worse, multi-tasking not only is likely to mangle the work, but it grinds people up and sends them looking for another job eventually... forcing you to bring in new people in the middle of a project and causing even more issues.

Other classic mistakes?

What other common issues have you seen derail software development projects? Share your thoughts with fellow TechRepublic members.

About

Justin James is the Lead Architect for Conigent.

61 comments
Barry Goldman
Barry Goldman

Great article. Its common sense really but it's good to be reminded occasionally.

And this is not just for software developers - I am amazed to realise how many of these 'mistakes' are apparent in the administration of Universities nowadays (where a lot of software developers are trained).

kenley22
kenley22

To stop making avoidable mistakes in project management one can also try attending PMP classes conducted by any of the PMI registered REP's for gainig expertise best processes of project management. Any good PMP prep course will provide students with lots of actionable insights in project management along with preparing them for PMP certification.http://www.pmstudy.com/

Treknology
Treknology

The first half of the project uses up 90% of the resources.

The second half uses up the other 90%.


If you really want a computer implementation to work properly, ensure that the people who write it also have to use it! The first major (like HUGE) database with which I was involved left the Data Entry Operators juggling at least six paper forms simultaneously because the people who designed the input screens hadn't even had the foresight to look at the source paperwork as a reference.


Does anyone remember that hideous "Chicago" font that screamed, "I have no idea how to use my Macintosh"?

ecommerece reviews
ecommerece reviews

Nice post! As i know that the everything is possible in the programming . No doubt, if someone change with the help of the nature , then it is only guess not give the exact location. So when you are starting to develop a software then you need to know the some information in which our software can do the some mistakes. ecommerce reviews Thanks for sharing the information.

B_Dillon
B_Dillon

I can't believe I got to the bottom of the comment threads without seeing a single mention of Requirements. Getting the requirements identified and documented accurately, having project sponsor and business buy-in of those requirements is an absolute essential to any project. My second key addition is the Business Case - how many projects have you seen proceed with a weak or with no business case. Projects with strong business cases can survive problems, projects with weak or with no business cases cannot.

jcllings
jcllings

Project owners and managers often don't get that almost every software project is an R&D endeavor which means that no matter how much you want it, no matter how you threaten or cajole, no matter who you fire or hire, it will take as long as it takes. The best one can do is inject predictability and consistency at every single opportunity you get. The entropy that occurs naturally within the system can also be managed within the system unless it is actually leaking in from the outside. Then it must be managed from the outside.

herlizness
herlizness

First it must be said and it must be acknowledged that estimating time in software projects is a black art. I have never seen anyone do it well and to pretend otherwise is pure folly. One of the big mistakes I see all the time is the failure to tailor methodology, metrics and PM to the scope of the project at hand. I don't know how many times I've seen teams working on relatively small line-of-business apps that have been treated as though they were working on *creating* the next version of the .NET framework rather than merely *using* the current one. What happens is that layers and layers of abstraction and administration are put in place that are not and will not ever be used for anything because the underlying business process is static. The related mistake is that more often than not all of these abstraction layers are poorly documented, if documented at all, with the result that a simple project (allegedly) designed for ease of maintenance is virtually impossible to maintain; when new developers come in, ramp-up times for them are extremely long, frustration levels high and, if they are sufficiently aggressive, calls for large-scale rewrites become the order of the day.

minstrelmike
minstrelmike

In our system, we work closely with the users and they have never wanted any sorts of reports on bug fixes or numbers of phone calls or anything like that. They just want the system to work. Our masters above in the organization keep trying to push us onto some help desk mgmt software but we get our users to resist. If the system is truly being fixed and training material is developed, then over time your total number of calls should go down but the average time per call should skyrocket. We try to avoid separation of helpdesk personnel and developers so everyone has a vested stake in a working system, not a broken system. Note that a helpdesk measured by volume of calls has a vested stake in a poorly-working system.

Mike_Prince
Mike_Prince

Maybe it's just me, but it's happened to me more than once... Knowing the products we make and having good requirements for a project, I feel I can make a good estimate hours estimate for a project. However, the project manager seems to think that an estimate of 120 hours will mean the job will be done in three weeks. While I, like many, work more than 40 hours a week, the 120 hours is the time I will be billing the project, not including admin time (manditory department meetings) or support time (since we support our own products). The project manager for the above 120 hour project was flabbergasted that I told him the development for the project would probably wrap up in four months, not in three weeks. (To note: We were going through a department restructure as well as coming up to a busy support season at the time).

harry.kron
harry.kron

It's amazing how many of these common mistakes boil down to perceptions, or lack thereof, about the development process.

Mark Miller
Mark Miller

Related to your #10, I worked at a place where I "evolved" into a multi-tasking role. It's not something I asked for. It just became necessary, because we didn't have the right mix of staff to delegate everything that needed to get done. I got a new project manager, after having worked there for 2 years, who assumed I would follow a linear schedule, but that was impossible. He didn't observe or ask me about my work flow at all. He tried to impose one on me, but if I had followed it, some IT operations would've fallen apart. I tried to explain that to him, but he didn't listen to me. He tried to compensate for what I did by reassigning staff to do some of my "diversionary" tasks. My memory is it didn't alleviate my multi-tasking, and he just had to deal with it, or else we wouldn't have gotten anything done. Just a word to project managers. It's very disconcerting when the software team feels like what you want is out of sync with what they know needs to get done. Depending on the makeup of the organization, people may have found it necessary to multi-task just to keep the whole operation "up." If you're trying to change the work flow by adding/reassigning staff, it's going to take time to do that. "Hit the ground running" doesn't work in this situation at all, and creates disruptions to your entire operation if you insist on it. Related to your #5 and #6, another problem with large teams is they can miss *huge* tasks, especially if parts of the team are not allowed to communicate with each other, and/or there's dysfunctional communication among the staff (possibly caused by management practices). At this same company, with the same project manager, I discovered a critical task that was not scheduled, and no one was assigned, *two days* before a large system was going to be tested by a client. It resulted from a miscommunication between a software architect and another project manager, who worked under mine. My project manager tried to coordinate a fix for the situation, but did it badly, because he tried to assign blame. I think the reality was it was nobody's fault. The right hand simply didn't know what the left hand was doing. It was a systemic failure. We managed to pull it out, and it was a contractor who I hadn't even met before this who saved our ass. He had been using his experience and a design discipline in his code on the affected system, which enabled me to coordinate a technical solution that a team I assembled could implement quickly, which connected two systems together. It was still a close call, though. We were literally testing and debugging the system, including our "fix it quick!!!" fix, up until 5 minutes before the customer did their first test on it. It was surreal. I always thought those scenes in action movies where something big is gonna blow, the hero pulls it all together in the end with a team, yells "NOW!", someone presses a button, and the system that saves them all starts up, and works, were just fiction! The customer didn't notice any of the chaos, and that's the way it should be, though of course we would've all preferred if the chaos hadn't existed in the first place!

rmhesche
rmhesche

These ten points are pretty universal so they should be part of any business curriculum. Probably several times. Sales staff make promises for things we haven't done before, the engineers hand us a stick drawing and the technician figures out some way to make it work in a time frame that has no basis in reality. Only to have the spec change, usually more than once, the engineer draw another line and circle on the stick figure, and once again the tech has to make it work. I've worked on equipment for earth, water, sky and space and the 10 points are universal. Same song with a different tune. Why should anything with computers be any different? .

RMSx32767
RMSx32767

"Hitting the ground running" also plaques the hiring process. Companies want a new hire to be immediately productive with little, or no, knowledge of culture, procedures, processes, business flow, and/or who-possesses-what-knowledge-skills-and-tools. The next thing you know the new-guy (even a manager) is suggesting changes to processes he/she does not even understand. Great commentary on the myth-conception of "multi-tasking". I've also seen "responsibility creep". i.e. a new hire brought in to work on a specific task then diverted, for whatever reason, onto completely unrelated projects. Needless to say it likely spells DOOM for the original project and its schedule.

The Management consultant
The Management consultant

Refine the project outputs in very clear simple terms,the core resources needed,define the critical success factors,modulisation has worked in the past,as well as dependencies, and time lines.These all were not in place when Bill Gates tried to develope windows Vista.The project was simply saved when Bill was taken off the project.A lesson learned don't be too ambitious.If technical innovation risk is required as part of the project make sure it is tried and tested before building the project.

JimMcKeon
JimMcKeon

Great list - every item is very relevant, practical, and concise. Regarding #10 (MutliTasking): what's the difference (not so much in definition, but in impact) of being in a multi-disciplinary role (like yours) vs. multi-tasking?

rgalligher
rgalligher

Excellent article - these points, all valid, apply to everyone on the team - project manager, developers, business analysts, testers, product managers, etc.

TNewis
TNewis

As a SharePoint Architect I thoroughly appreciate this list. Unlike many of my colleagues who???ve have a strong development background, I???m more business focused; in more of an Engagement Management role to gather requirements and provide the initial translation to a high level solution design before the dev team gets involved. The point about communications is so important, and while criticism flies around as problems occur, is the responsibility if the business and the dev team to stay in touch, this process is much like a marriage; we all have to be on the same page. A clear deployment plan is also very important, as soon as the business gets their first taste of the solution the inevitable scope creep starts; ???oh, that???s cool, but can we???.??? But we???re still trying to bug fix. There so many aspects of SharePoint solution deployment that this list provides a great starting point to keep things in perspective. All too often the kick-off doesn???t set realistic expectations or there are misunderstandings that don???t surface until later in the project, so have a foundational checklist is always a good idea.

dimonic
dimonic

The mistake my company makes (for the 6th time since I have been here), is that it requests time estimates from developers, then routinely overrides them. People are essentially intimidated into giving time estimates that coincide with managements schedule, rather than based on the work to be done. Then we routinely overrun - usually to the "internal" time estimate and maybe a bit more, and morale suffers.

Slayer_
Slayer_

We do that now. Management solution to lower the bug count? Take 2 programmers and turn them into CSR's. Yeah, it reduced bug count, because there is less development going on. Now they are trying to figure out why work has slowed down.

Manasa Bharadhwaj
Manasa Bharadhwaj

Justin, is this a part of the software engineering myths mentioned in the book 'The Mythical Manmonth' written by Fred Brooks?

phil_simon
phil_simon

I hadn't heard of the pregnant woman mistake and wish that I had added that to my first book, Why New Systems Fail. Great list. Phil

Professor8
Professor8

Every project requires some experimentation. And I've never known anyone who was able to predict how many experiments would be required to develop a new way to do something, how many potential approaches and sub-approaches may be required in the mean time, and/or experiements to compare various ways by various metrics.

elmramir
elmramir

These are all great mistakes to mention, but changing requirements during the project build phase could be the most pernicious. Unless there is a substantial benefit, project leaders should push to add features at a latter phrase.

astevens009
astevens009

...12 years ago when I needed someone to affirm my observations that multitasking JUST DOESN'T WORK? :-) I'm from the school of thought that doing "one task at a time" allows us to focus on the task at hand and in so doing, we take more time to plan ("measure twice...") get it RIGHT ("...cut once") the first time through...

kci833
kci833

What happened to Requirements Management ? Does the author assume that 'ALL' requirements have been nailed down. I've seen some projects where the originator of a requirement changes it in midstream of the project taking it back to square one (time wasted). Agile, RUP, CMMI and other process improvement methods address requirements, but when the man with the money changes requirements, he then has to reach in his pocket and sometimes he doesn't like to do that !

ittechexec
ittechexec

Great post, Justin! I agree that all of these are major factors in why IT projects fail and why IT is often not viewed as a valued business partner and more of a necessary evil in the business. Here's blog post with some additional thoughts on IT project failure centered around the Business Analyst role. It's got a short, 1-question poll at the end, so please share your thoughts on it. Thanks! http://mdalums95.wordpress.com/2012/04/05/cio-it-career-project-management-how-to-plan-for-success/

Ole88
Ole88

If a PM or team manager can't say no, scope creep comes into play too often. You have to know when to say "yes" and when to say "no, that will wait for the next version or update."

reisen55
reisen55

Study SAIC and CITYTIME to learn everything about a totally botched project. And do not EVER send software development to India.

Ray Baker
Ray Baker

That's what I called number 1. It applies to all cases of project management. 20 years ago I too was against (leery) of multitasking, it doesn't work!

viggenboy
viggenboy

I seems to be especially the case working for the public sector, but the ever moving target, and/or flip-flopping of or specification of conflicting requirements has been the biggest bug-bear in over-running -projects I've been involved in. How many progress meetings have I endured the heads of two user departments bickering about their requirement being more important than the others, or the "that's not quite what we meant when we specified this".... "oh hang on yes we did".... "erm did we?"... "oh that was before we has the re-org, but now..." This is what leads to the process wall, as the bickering turns to mud-slinging in which the only place it sticks is on the development team.

26Alfred
26Alfred

A common hazard is taking too long a view, plan too far ahead and show no intermediate results to the end users. The result is a project that gradually looses credibility and support. The end users generally react negatively when (finally) results are shown to them. In a worst case scenario the goals to be achieved may have changed over time, rendering the project results partly or totally useless. Stick to incremental result delivery with a max event horizon of 4 to 6 months!

GrizzledGeezer
GrizzledGeezer

I'm told Microsoft does this, and it is surely not alone. It can be seen in the gradual deterioration of such products as Word and Visio. There should be no more than one or two people who make decisions about features and interface.

Bareng
Bareng

Not having a good induction plan (in the coding team) to introduce the new comer to the project e.g coding standards, code architecture and special components used in the software development process. This might be a resource consuming activity in short-term but it pays out in a long run

GrizzledGeezer
GrizzledGeezer

Point #1, about not throwing large numbers of workers into the pot, has another aspect that's often ignored. The more people working on a project, the less each is responsible for its success. This works against a sense of individual responsibility, and the resulting pride "in a job well-done". Workers should be added only as they are actually needed.

ktw.zd.net
ktw.zd.net

Very good post, very well thought. My favorite is #9 - nobody ever thinks about a person added to a project will need to be "trained" on that project, and also who will do it. The worst is interns, not that I don't like interns, but I slows you down when you have to teach and do at the same time.

neilson
neilson

Tech companies seem to have a special skill at failure to communicate. In my work as a software developer and tech writer I have observed several difficulties: - Failure to keep projects secret from competitors by failing to instruct developers on secrecy. In 1976, as a DEC customer, I encountered one of DEC's dev gurus at a party and asked him about the possibility of a 32-bit version of the PDP-11. I waved my hands describing two possible architectures, and may have mentioned Multics-style virtual memory. He said, "I know too much to say anything, but basically you are correct." Oops! If I knew about it, then everyone on three planets knew as well. My friend and the rest of DEC's VAX team should have been instructed to say, "Fascinating," and nothing more. - Failure to give secret knowledge to co-worker teams. Too many times I have seen the doc group get a request for documentation for a product just six weeks before its shipping date. Frequently the tech writer finds blocking bugs as she explores the product, and of course she gets blamed for the slippage. - Failure of management to listen to "the trenches." This is your classic Dilbert storyline, where management punishes messengers who try to get help for problems that the developers are encountering. An infrastructure to hide bad news from management develops. - Operation of hidden agendas. The folks in the trenches never find out until much later that their much-touted project was deliberately doomed for some nefarious purpose. The company's stock zooms and crashes on schedule, management's confederates make a bundle, and any whistle blowers are accused of paranoia. The best employees leave in disgust, management "restructures" the remainder, but cannot attract creativity while forcing it away, and bankruptcy follows. It's not all gloom. Occasionally things go well. Lessons from Moore, Brooks and Ershov are applied, excellent software and hardware go out the door, operation in the field is straightforward, IT crews are slightly happy, and customers are pleased.

Tony Hopkinson
Tony Hopkinson

Premature optimisation, turd polishing, dashboard mania, reality being incorrect as it doesn't match the plan, scope creep, the agile waterfall development lifecycle, technical debt, releasing prototypes, ad nauseum In short a failure to realise that this is IT and change is a given.

framefritti
framefritti

I work in a University, not in an enterprise, but nevertheless I recognize some situation I went (and I am still going) through... 1. I also call this "the single shovel syndrome." The name refers to a commonly made remark about road works: "When there is some road maintenance work, you see ten people, but only one is digging." Although, personally, I do not believe that this is always true, it could actually happen if your work plan calls for a hole to be dug and there is only one shovel: it does not matter how many people you put a work, only one will be able to help. This is actually a bit different from the "pregnant woman" effect: pregnancy is a strictly sequential task and it cannot be split in parallel, hole digging can be split, but you must provide enough resources (shovels) to get advantage from parallelism. 3 & 4 (about time estimations). When we submit projects to the EU for funding we are asked for a timeline that extends for 2 or 3 years. We should specify how long that workpackage about development of a cloud 3D sharing platform (or whatever) will last. My first reaction is "How in the (whatever) am I supposed to know?!?" It depends on many variables that, since I do not have a crystal ball, I am unable to predict... It depends on the ability of the people that I will hire to write the software, it depends on the outcome of other WPs, we could have problems in getting SW and/or HW that will delay the development. In these case I (like anyone else, as far as I know) just throw some numbers that can look reasonable. BTW, I decided to read Brooks' book to actually get some hints about stuff like this. 9 & 10. I summarize this in the motto "people are not computers." With computers you can expect them working since the time you plug them and you can use them with lots of different tasks, but people do not work in this way; they are more slow, more "low pass" (to use an electrical expression) and they have lots of overhead when switching tasks. I see 9 especially with some people from industry that come to me with a request like this: "Oh, we need some young graduate, it must be an expert on (a very obscure piece a SW that only they use), since we must deliver a product in two months and we are searching for someone who will be productive since day 1." Typically I am kind enough and tell them that I will ask around for someone, but in my mind I think "You just got your times wrong," ask to a couple of people (just to say to myself that I tried) then remove their request from my mind. I see 10 with many coworkers of mine. They get a student to work on some project (that does not interest them, but it is founded) and they would like that the student worked also on a different project (that interests the professor more, but it is not directly founded). The overall result is that, if correctly handled, the student does a good work only in one project, otherwise does a bad work in both projects.

gansenhaut
gansenhaut

Justin, apprecieate the post. My views are related to the "Wall of Process" or managing the changes of requirements that appeared to be poorly documented by the "business" (even if detected by risk-analysis, the business claims to be able to provide the details if requested), the change of persons (business' POC changed three times, got overcommmitted, do not remember, unable to understand the questions of the contractor, ...). So I decided to build upon the US DoD practices of "Request for ..." process. Here again, we had to define the process ... business rejected the procedure (we are perfect syndrom), Contract agrees but once needed, Legal and I stated that the company is mandate to write down all their claims (Conformity, Price, Delay) if it impacts the contract. So, company and customer share the "wall process" .. I do the initial draft and they complement my questions. To make it short, this is about documenting changes of personnal in case of claims. In Public Procurement, there are penalties for late delivery including non-conformity to specifications.

SpiritualMadMan
SpiritualMadMan

Your #6 hit then nail on the head for me. I just left a Software development project after having been told I was not a programmer, and locked out of the loop. Even though my project will be distributed. They will have to rewrite a lot of it because I was not privy to their discusssions. And, therefore, not compliant to thier standards. Without communication there is no collaboration, no synergy and the final product will never be as good as it possibly could. I remember videos of the early Atari crew in all their capes blowing off steam. That comraderie made Atari a leader for quite some time.

miwjones1
miwjones1

Justin, I really like this post. From my perspective the biggest hurdle out of the ten is constantly facing the 'Wall of Process'. This is especially true in larger ITs when we are working in an Agile manner and their processess have been established to 'control' everything. I like to think of this as the Productivity to Risk model. The more an IT tries to control risk the less productive they become. Of course risk mitigation is warranted; however, the problem is that many ITs only have one risk management process which is set to deal with the highest degree of risk making everything terribly inefficient.

doug.duke
doug.duke

... or cure world hunger. Many projects are just too big, covering too much scope. In many cases it is better to move forward incrementally - even within a larger scope of work. Concentrate on getting a well-defined, easier-to-manage set of tasks delivered and bedding down before moving forward with the next. In many cases, massive "big-bang" data migrations fail due to their complexity or end-users simply cannot absorb enough simultaneous change to support successful project completion. Note: I don't even necessarily mean use a Rapid delivery methodology here ... just define a scope that is plausible and deliver it. Success breeds success.

Editor's Picks