Enterprise applications, “I.T. 2.0” and the previous releases

This stuff from ReadWriteWeb is great. It shines a light, regardless how ephemeral, on “processes,” “running a business” and how “technology can help.” Even in the Enterprise.

These are Good Things for ReadWriteWeb, Good Things for collective Readers, and Good Things for Mean Business.

But I.T. 1.0 isn’t yet fully-baked. I.T. .9 (beta!) is hardly there in a ubiquitous way.


is a simple, hackneyed example.

We certainly don’t begrudge The New, New Thing, but there’s about 30 years worth of New Things that can yet be leveraged to more serious business advantage.

This isn’t advantage in the sense of “I have it and my competitors don’t,” this is “I’m being smart with my business, taking advantage of things – technologies – available to me, and making them work for my business.” (in this sense, many of your competitors don’t have it …)

Are the “new technologies” for business – wikis, cloud services and doc versioning platforms – so much different from the knowledge bases, time sharing and document fileshares that have been available – and underutilized – for years?

We love the “self-provisioning” userbase in Enterprise 2.0. It’s better even than User Generated Content: This is people NOT calling support lines and instead Doing Their Thing without our help thanks to the wonderful knowledgebases we’ve put together. This works, to be sure, but it wasn’t fully sorted out – or put in effect – in Enterprise 1.0.

Better searches, instant feedback, and peer recommendations / edits / contributions will help, but it’s mindset that will make the difference: Adoption out of need, want and executive mandate is what’s required for now to get this stuff inside – and working – in the Enterprise. (That’s grassroots up and management down.)

Launching: Good Enough vs. “Perfect”

The cast of “Product Chefs” is expanding. A year-plus extremely-rapid design, develop, release, refine is quickly becoming design, deliberate, design, deliberate, develop, deliberate, design, deliberate (you get the picture). 

I have definite ideas about how wrong this is in this current environment, but I’m too experienced to think mine’s the only – or only correct – perspective. My feeling is you work on the bulk of the product – the 80% – get that correctly-positioned for release and refinement and you go. Your audience is going to be your best source of feedback, and you’ll never be able to test every usage case beforehand, anyway: get it working, get it out, and get ready for audience feedback to inform your plans for Release 1.1, 1.2 and beyond. 

At what point does it make sense to be more concerned with the 20% (as opposed to the 80%)?
When should your company (any company) be more concerned about Getting it “Perfect” than with “Getting it Launched?” (air traffic control, financial systems and the like aside)

Those who feel charged with “protecting the Brand” can generally make a case that just about anything is not yet “ready for prime time.”  

In more jaded moments, it’s easy to point out that

  1. Success breeds envy; when something starts working, people want a piece
  2. When a product is designed by committee, each member can claim their piece of success upon success; upon failure, there is near-zero culpability 

To the other point of view, however, maybe it’s upon success that you start taking a harder look at the 20% you’ve been neglecting in initial releases. It slows you down, but with more eyes on you, maybe you need to adjust design, develop, release, refine to account for more upfront.

Managing Expectations in Project Timelines (with FAQ)

As we’ve delivered products through the years, managing timelines – and stakeholders’ perceptions thereof – has been an interesting source of teachable moments.

The snarky note below was for a core team-only. The tone in it is not recommended for general stakeholders. The FAQ covers two main recurring points; additional contributions would be great – please send them.

Our April 11th due date for Final Design approval and sign off is now missed by at least 20 days. None of the later milestones, therefore, were hit. Everyone should understand that the other dates – Production, Coding, Integration, Testing, Launch – move out accordingly.  Even so, I don’t want to presume this understanding is there throughout the rest of our extended team, so I’d like to send a new timeline out to everyone. I’d also like your help in backing me up and reïterating this message. 

I have some FAQs prepared that I can send (e.g. “Q: But you said Launch was May 15! How can it not be May 15!?”; “Q: But this latest design is so much like the existing design! Doesn’t that mean it’s really easy to put in place”)

Thanks, and please let me know if you’ve got feedback for me before I circulate our new timelines for this relaunch.

The Team

Btw –

A: Because of the relatively fixed nature of the space / time continuum, moving one point affects the other points in a directly-proportional ratio
A. No – it’s still a design job that requires Design, production and coding that needs to happen with the same resources we have in place today.

Corollary: “Q: So, can’t we get some more help to speed it up? More designers, Producers and coders to still hit our date two whole weeks from now?”
A: Sorry, but no. Especially in such tight timeframes, adding additional resources does not automatically mean our time-to-market improves. Getting external resources up to speed could help in a longer-term project, but not one that’s expected in just a few weeks. A re-launch project like this is like giving birth to a new life. Giving birth takes about nine months for humans. Adding additional resources to the pregnancy will not speed up the birth.