Biting off more than you can chew?

 Dog eating a watermelonI saw this Harvard Business Review stat that claims one in six IT projects are money pits, going on average 200 percent overbudget and taking 70 percent longer than planned.  I wonder what would happen if we could see only nonprofit IT project performance--what would that look like?  I suspect not much better, and possibly even worse on the scheduling side, as that's certainly been my experience. It makes me think that nonprofit organizations have a tendency to want to bite off more than they can chew when starting a new technology project, and this adversely affects the project.  This may be because the organization doesn't really know what's involved in--for example, setting up a new fundraising database or redesigning their website--or it may be that organizations simply don't allocate staff time for people who aren't "directly involved" on the project.  

Regardless of whether an internal IT person or consultant is assigned one of these projects, it's their responsiblity to make it very clear assistance is required from the rest of the organization, both in terms of staff time required and skills required.  I really enjoyed this post by David Geilhufe on the NTEN Discuss List (of course, you're an NTEN member, right? Right?!) which talks about a few of these issues.

One of the main responsiblities of the IT staff (or consultant) will be to divide the project into easily digestible chunks.  This work entails dividing the project into phases, defining clear business goals, assigning people to the project, and other steps.  Often this simply isn't done, or is hurriedly rushed through because "we need that website live next week!"  This is not a strategy for success, and then the organization gets into a downward spiral of "we need A, but it's taking too long to get, so we'll just assume B, and move on to the next item: C," which ends with no one being satisfied because what was created was not what was expected.

The attitude that "the technology will save us" seems to somehow prevent many organizations from doing much of this up-front work (planning, defining clear goals, process mapping, assigning people to the project, breaking projects down into pieces) required to have these technology projects be succesful.  You wouldn't roll out a new Homeless Prevention Initiative without doing up-front planning, so why would you think IT is any different?

Thoughts from the field?  How are projects handled at your org?  Are you biting off more than you can chew?


ah hah! I *thought* it was IT's responsibility

How nice to see that dividing the project into phases, assigning people etc.  is the responsibility of IT.  If only it worked that way here.  I'm the program person assigned to do all that and present it to IT, with little to go on.  Which feels rather unfair and doomed to fail.

Since I'm living this right now, let me specify some of the "other steps" I'm attempting to present to our team: identifying cost items (if not dollar amounts) and ensuring that each department knows which costs belong to them; defining future training that will be needed to operationalize the new tech system; building in a couple "stop-loss" moments when we have the right to say "this isn't going to satisfy our needs'; building in sign-off documents so we know when we're authorized to proceed; estimating (and charting) a timeframe of how long each step should take; recommending incentives/rewards for the partner orgs who are being asked to help test the system... have I missed anything?

Any tips on how to get IT to look at, comment on, and stay accountable to my big plan?

Project Planning is more than a buzzword!

 Thanks for the great post Marc (and the membership plug!) I agree with you 100% - proper planning too often takes a back seat to quick implementation. The thing I think is most dangerous (and most missed) is the goal setting. When you think about, say, upgrading computers for office staff, it's easy to think that goal setting is silly. The goal is that staff get new computers, right?  Wrong. The goal is that staff get new computers - FOR A REASON. What are those reasons? Do they need more memory to support graphics programs? Do they need more hard drive space to store large files? What those staff are looking for - their goals - should drive what you install. We have to set goals, or at least define success, with all the players if we're going to succeed in any IT implementation.


Holly, great point about goal setting.   It's so true that people often skip past the "WHY" and just jump into the "HOW" because in some ways it's easier, especially if you're a technical person.  The goal setting can sometimes be a difficult process involving facilitating conversations with many people within an organization, and often this isn't a "techie's" strongest skill (myself included!).