January 25, 2010

Updated: How to ensure your document assembly project fails


As with all IT projects, there are a number of sure-fire ways to send a promising document assembly initiative off the rails. And that's regardless of how good the technology is.

So, what can you do to turn a great idea into an unmitigated disaster?

Don't tie the project to a pressing business problem
The technology's cool. (Company X implemented it and they love it.) Plus we've got 'use-it-or-lose-it' budget we have to spend. We don't need everyone to agree upfront what success will look like. We'll find a business problem to solve along the way.

Skip planning
Clarify the problem? We don't have time to do all those workshops and all that analysis stuff. Everyone's way too busy with their day job. And the users don't know what they want anyway. Better to leave them alone. We'll just make some assumptions.

Encourage scope creep
It's good to keep adding things as people think of them. No need to get hung up over importance or competing priorities. The more features the better. Usability's overrated.

Avoid change management
Of course we want people to use the system. But, we're running out of budget. We can't waste time listening to them complain that nobody spoke to them. This is the way it's going to be. They can like it or lump it.

Don't seek executive sponsorship

The executives don't get it. Better to fly under the radar and then show them what a great job we've done once we've finished.

Update: Boil the ocean
A phased approach? That's for wimps. We're going to tackle everything at once. That way we'll be sure not to miss anything important. (Thanks to MAC for that tip.)

It really is the case that "the soft stuff is the hard stuff." If your project doesn't have capable, motivated team members backed up by strong stakeholder support, it doesn't matter how good the technology is. The initiative will fail.

Related posts:

Document Assembly Solution: Buy Vs. Build

Why Complexity Matters

5 comments:

  1. I believe you could miss the acronym 'IT' out of the first line - this type of approach sends ANY project off the rails!

    ReplyDelete
  2. You missed:

    "Start out really big.

    No point in solving a small high return part of the problem first when you can make sure to involve all departments with conflicting ideas, agendas and different legacy systems. People always trust your vision documents and slideware more than a system that demonstrably solves a problem."

    ReplyDelete
  3. Margaret - I agree. It does have general application.

    MAC - Thanks. Great point. I'm going to update the post with that one.

    ReplyDelete
  4. To set the focus on document assembly again:

    (1) Documents
    "Don't waste your time analysing the documents. A rough overview is sufficient. There can't be a lot of hidden logic in documents, can it?"
    (2) Ressources
    "Don't use your experienced staff in the project. If you must hire consultants, don't let them discuss occurences of a document with people working for billable hours. The intern or the trainee will do it, too."

    ReplyDelete
  5. Anonymous - so true. These are two great examples of document assembly-specific items that can kill a worthwhile project.

    I think I might do another post on these and other important activities specific to document assembly.

    Thanks, Andrew

    ReplyDelete

Blog Rankings

Technology Blogs - Blog Rankings