tdog.blog

Intelligent Enterprise reports the results of its 2006 Intelligent Enterprise Strategic Management Survey that the top two IT expenditure priorities in the coming year are security/privacy (51.2%) and content/document management (50.2%).

Some interesting insights came from the survey:

Why the increased interest in document and content management? One possible explanation could be found in the fact that 50 percent of respondents confessed their firms make poor decisions because users can’t get enough good information. Ranking various sentiments on a scale of one for disagree strongly to five for agree strongly, 36 percent of respondents (the largest share) were neutral on the statement “our company has selected an enterprise content management standard and is consolidating on that platform.” Meanwhile, 32 percent agreed somewhat with the statement “our content control needs are basic and are addressed by network directories, intranets, basic document management and/or portals.” And 33 percent agreed somewhat with the statement “we’re moving toward XML-based management and reuse of content across applications, departments and channels of communication.” (emphasis added)

Check out the whole article.

Comments(0)

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.

Comments(0)

1. Put three clear reasons on your home page why I should buy your product or hire your company. And phrase it in such a way that I can easily understand what you’re saying.
2. Put five links on your home page that drive traffic to latest news about your company, a white paper, your blog, or product/services pages. Make it a point to drive me deeper into your site.
3. Put together a page of testimonials and link to it prominently. Testimonials should be short (2-3 sentences), as specific as possible about your product or service (avoid the “you guys are great!” syndrome), and should always be signed with a full name, title, and company (if getting consumer testimonials, first and last name, city, and state are sufficient).
4. Put a call to action on each page. A good place is anywhere close to your search widget, or barring that, in the upper right hand corner. It can be a link or an image that drives visitors to a form they can fill out, or it can be an exortation to call a toll-free number.

Comments(0)

Okay, so you’re about to launch into the brave new world of dynamic web sites. You’re gonna get the fully-loaded sales lead generation tool that integrates with a CMS and has database publishing capabilities. Cool. But before you can sign off on the deal, you have to figure some things out, which means having a chat with the folks in IT. The last time you talked to the guys in IT, you couldn’t really make sense of what they said, but it all sounded really good.

If you’re in this spot, you’ll need to go in there armed with good questions. Here’s a list of starter ones, divided into categories. Compatibility questions can give you a lot of information about what IT supports (or can support) right in house. Responsibility questions help IT formulate who is responsible for what systems–a very important thing to IT. Integration questions help you and IT discuss how to take the new system you are buying and place it in and among other existing systems. Scheduled maintenance and backups questions provide you with an opportunity to find out how robust your IT department’s non-emergency capabilities are.

Compatibility
1. What kinds of servers are we running?
2. What OS (usually Linux/Unix or Windows) and at what versions?
3. What databases are we running (mysql, postgresql, sql server, oracle, db2) and what versions?
4. What scripting languages do we support (php, asp, jsp, .net, python, perl, ruby) and what versions?

Responsibility
1. Do we need a service-level agreement? (SLAs are like contracts that guarantee certain percentage of uptime per month, or a certain response time to incidents, etc.)
2. Can IT support this project in-house, or if they can’t, can we outsource to the vendor?
3. What contact information do you need from the vendor if we do outsource it?
4. Does IT prefer or require a testing period or pilot program before full implementation?

Integration
1. What information do you need to have from the vendor about integration issues?
2. What information do you need to give to the vendor to make integration succeed?
3. Is there any offline or online documentation we can share with the vendor?

Scheduled Maintenance and Backups
1. What is the maintenance schedule for software, hardware, or OS in question?
2. What is the upgrade schedule?
3. What is the security patch schedule?
4. How often is the data backed up or mirrored?
5. Can we outsource backup or maintenance/upgrades of the application to the vendor, or does it need to be handled as part of a larger IT program?

Comments(0)

Two interesting stories about outsourcing to rural areas in the US or to Indian tribes (and don’t give me any of that “Native American” malarkey, I’m 1/8th Iroquois and 1/4 Guaymi from Central America, and let me tell ya, nothing is more annoying than the PC gambit).

Outsourcing to the Heartland

…clients benefit from local accents and similar time zones — not to mention the absence of stigma sometimes attached to farming jobs out to foreign countries.

American Indians helping ease outsourcing quirks

“In many ways, American Indians are entering the outsourcing marketplace at a good time. There’s plenty of work to be had, and for some CIOs the offshore honeymoon is over,” he said. “They’re looking for a low-cost and high-quality onshore option.”

Comments(0)