Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

1. Lop off any non-essential folks from the stakeholders list. Make these non-essential folks advisors or reviewers. Try to keep your primary stakeholder list as small as possible, and by that I mean 5-7 or maybe 9 max, not 20. I’ve been on projects with as many as 50 stakeholders, and that’s just miserable.
2. Don’t rewrite what’s already working. If you’re project includes writing functionality from scratch that already works elsewhere, really examine your motives carefully. Are you rewriting it because of not-invented-here syndrome or because the existing stuff doesn’t work or scale to your needs? If the latter, okay. If the former, leave it alone and figure out a way to integrate!
3. Prioritize! Take your entire list of requirements and categorize them into three groups: Must Have, Should Have, Nice to Have. Then sit down with your developers and figure out each item’s impact. You might figure out really quickly that all 9 items on the must have list put a serious dent in your budget and talent pool, but by tweaking 3 of them just slightly, you could actually save 30 days worth of work. Launch only if you have all the Must Haves and as many Should Haves as possible. Leave the Nice to Have’s for a future project.
4. It has to have kitchen logic. Many requirements will come in under the broad category “Wouldn’t It Be Neat If” or WIBNI. A colleague of mine from the Vignette days termed this kind of requirement, with its wild and crazy roots, as “science fictional.” You’ve heard of these. “We want our Web-based sales-lead generation tool to provide real-time data reports 24×7x365.” No matter that implementing true real-time anything means quadrupling the load on the system and tripling implementation costs and timelines. (However, a near real-time system can offer 90% of the benefits without too much added work!)

   Requirements have to have kitchen logic. You know what I’m talking about: requirements have to communicate a benefit stated in language that anyone can easily understand and relate to. Why go with XML? Is it because the three-letter acronym is so neat, or because every other article says we should use it? No! We should use it because it is easy to translate any XML document into other formats, which our particular organization needs.

5. Manage expectations. I’ve been on plenty of projects that start off as the equivalent of the Wright Brothers at Kitty Hawk, NC. We work and work and work and work and finally get off the ground for 30 seconds. Everyone is disappointed in the outcome. You ask why this is so and find out that everyone was expecting the team to put a man on the Moon. Even after you point out that the 30-second flight was something unheard of in the industry, everyone is still nonplussed. Why did this happen? Because one influential member of the business management team decided to share his vision via PowerPointware.

   A very wise man, my jeet kune do sifu, once told me that “An expectation is simply a resentment under construction.” Live by these words.

The problem in most cases is that IT abdicates its role as an equal partner at the table, either because of custom, board room politics, or just plain eagerness to please. Stop it. Draw some boundaries. Stand up for yourself. Remember: as an IT professional, you’re there to help the business leverage the power of your skill, intelligence, smarts, savvy, and geekitude to make the business more profitable.

Bookmark:

Tags: No Comments