My youngest teenage daughter looked over my shoulder as I typed, and asked her usual, “Whatcha doin’?” I replied, “I am writing a Blog for AIIM. They have invited me to write.” Then I made the mistake of throwing in a self-deprecating, “Some people think I know something.” Her quick retort: “And when will you inform them that you don’t?” Kids! So, I am informing you. Enterprise content management is a fun business, for me at least, and I have learned a few things, but I also know my lack. Thus completes the disclaimer.
The Winchester House in San Jose, California, was under construction for nearly 40 years and is full of architectural oddities and marvels: stairs leading to the ceiling; doors and passageways to nowhere, to windows, or doubling back; rooms added to rooms onto other rooms for decades, long after the original structure was built. Now it towers to seven stories in places. It claims its share of ghosts and strange events, too – banging doors, moving lights, not to mention the spirit of Sarah Winchester herself walking about. It is a cliché. Anyone who has been in I.T. for any time has heard about the house and cited it, but I still see the house as a wonder and consider the obvious similarities to many mission critical projects, as well as to simple applications that have devolved to dead ends and trap doors. Seen any ghosts lately?
Somewhere, there is a business portfolio manager who really does not know Shinola. However, most understand their business, processes, and tasks very well, and are more technically savvy than ever. Yet, they have difficulty developing requirements for I.T. projects. I.T. processes are arguably more regimented now, capable of predictable, repeatable results. The I.T. staff is much better trained than when I started my career, and the tools we use are full featured and reliable. We can do amazing things given half a chance. Yet, requirements gathering takes very strong people skills, traits not generally associated with engineers.
Come Implementation Day, and we hear the customer lament, “This may be what I asked for, but it is definitely not what I need.” Then, the programmer lament, “Pasta Fazul! How’d we miss it?” Perhaps we find, as one client did, that the business requirements grew 40% between the conclusion of design phase and implementation! What happened between the first team lunch and post-launch review? We’ve heard it before. Scope creep, miscommunication, poor design, poor execution, and mismanaged expectations all blamed as usual, but why is it “as usual?”
You can drag out all the scope change documents and emails you want, but bottom line, we do miss it a lot. Maybe it is high time to place the blame where it belongs – on our customers. The a priori assumption in all I.T. projects that make it past detail design phase gated funding is “The customers know what they want.” What if they really don’t? What if they can’t know without a great deal of help?
The focus here is on enterprise content management projects. I have a good friend who is also a principal architect for one of our clients. He and I have been discussing for some time how to arrive at articulate and accurate requirements for an ECM project we are on. Several of his company’s departments are considering Web and portal content management. It’s an enterprise effort. So they are investigating a number of vendors. Many of them have come for on-site visits and product demonstrations. The products present dazzling features and blinding performance, and the evaluation team has grown weary of it all. The products all seem to offer the same things – the commoditization of ECM as John Newton has predicted is evident. One of our client’s SMEs and a business lead for the team has a four-inch binder full of product information that she has been divining like the Da Vinci Code. It’s been eye opening, but now our client needs help to sort it all out, and to articulate what they want and need, and then pick the vendor who meets the need.
So the principal has an idea. What if we built a prototype, in a very short time, with the sole deliverable being a set of requirements that the business can present to the vendors? The typical application of Waterfall Development to the prototype would take too long. He used Agile Development on a very successful project. However, his previous success and the success of others such as American Airlines, did not garner support from his peers and management. Agile Development gets a bad rap in some circles. Further, using Agile Development to deliver a set of requirements and not the finished product is unusual. So here are some questions for you:
- Do you apply a development methodology to ECM projects? Which methodology?
- How do you develop detailed business requirements for ECM vendors to meet? Do you use prototyping to develop requirements for OEMs?
- What resources, talents, skills, and support would you need to quickly develop prototypes with enough functionality to give the business end users a good idea of what they need in ECM? Could you do it in three to four weeks?
- Is Agile Development applicable to deliver detailed requirements via prototyping? Why or why not? What about using some other rapid iterative approach – would it work or not?
I’m not fishing for information. I know how our client is answering the questions and how we’re helping him. I want to know about you and how you handle this common problem in the context of an ECM project. As our project develops, I hope to be able to report some results to you.
Talk soon.
- Bill Hunton, Armedia, LLC