It is rather surreal doing this blog post. I feel as if I am in a re-run of “Back to the Future.”
I am putting the finishing touches on this post before I present the session KEG, but because my internal clock is still set to Australian time, I am really doing it on the day after. These are some of the problems in living life “Down Under,” or as we Australians think of it, “Up Over.”
Other problems include the “two nations separated by a common language” that I encounter every time I visit. Please don’t ask me what team I “root” for or whether I would like to buy a Denver souvenir “fanny-pack.” Be careful asking me the way to the “bathroom” as it will get the response: “I’ve got a bath in my room, haven’t you?” We only have loos, dunnies, lavs, bogs or, if in polite company, toilets, and I take great delight in directing any American visitors to the room in my house that has only a hand-basin, shower and bath and not the other small room that has the toilet pedestal and watching their faces when they return with cleaner hands but a slightly more distressed look.
But enough of the cultural differences.
A little about myself and why you may be sitting in this presentation (if so, please put the iPad away and look at me) or reading this alone in your office or home (I assume because you have come to such a boring moment in your life when reading a blog entry of mine adds some excitement).
Well, I discovered the other day—through an automated message sent by our internal version of Facebook called Yammer (hopefully I get something for the plug—but not another bloody t-shirt please) that I have been with Kinetic Data (hereafter, KD) for over 8 years! That re-assured me, because I thought it had been forever…
I also have to admit that I am the oldest person in KD—but of course this does not mean that I am the wisest—as this blog post is proving!
Prior to KD—I can dimly recall that there was such a time—I have been with a number of IT companies working with BMC Remedy and other applications (they do exist), many of which have now melted away like the snow flakes which may be falling outside, when the sun warms them.
So, I hate to admit it, but I have been in this industry for over 40 years, so probably before most of you in this room or looking at this blog post were even in “project initiation phase” and probably before “requirements gathering” and putting out the “RFI or RFP.”
Since then I have worked as a Consultant, Analyst, Designer, Project Manager, Developer, Trainer and even once, on the “Dark Side,” as a Client in this industry of ours.
So, I think I have a right to have a few opinions on this whole “Requirements” business. Hopefully these opinions will inspire some thought, maybe even controversy, and hopefully someone might feel interested enough to have bought me a drink (Single Malt Scotch over 12 YO) to get me to share a little more of my “wisdom.”
OK—here we go.
I was told my Power Point did not have enough bullet points, so I added a second Agenda page. Apart from these two pages, there will be:
NO MORE BULLET POINTS! JUST PICTURES.
This achieves two things: 1) you might listen, and 2) I don’t have to think of another way to say the same things without using the words in the bullet points.
(For those reading this blog, who want to look at the pictures, someone will have posted my presentation somewhere on the KD website—so you could download it and enjoy the full experience of course, without the “gosh I like the way you Aussies speak” audio component.
Let me “share with you” my first EDP (look it up) job, programming a door opener. I got paid about $50 for it (in those days that would be USD25—now it would be USD60—how the weak become the strong). After the stunning success I had in fulfilling the requirements—door must open, door must stay open for a while, door must close—the requirements were expanded to encompass the concept of “small room – moving up and down in a controlled way,” so I programmed a bigger controller that incorporated all the great work I had done with the “Project Door” and added moving a room up and down in a vertical shaft, stopping and then doing the door bit. We called this “Project Lift”—or in American—”Project Elevator.”
This was the first time I had been confronted with the idea of requirements analysis in the “real world.” I was obviously excited.
They were simple requirements. We did have a discussion as to whether the doors should open in an “organic, caring and cool way”—it was the 70’s—but we knew that person was a closet hippy, so we ignored this suggestion and just went for “slamming open and slamming shut.” A lot of people nearly lost limbs because of this —but I had the cheque (check) and had moved on to bigger and better things like the Traffic & Parking Infringement Notice system for my home state (Australians have the same urge to make an acronym of everything—that is, when they cannot add an “ie or y” to a name—and we called it the “Project Tin-Pins’.” Yes, there were nerds even in those days and we were they.)
So that brings me to the point of the is session.
How to achieve a successful Kinetic Request project—and—taking a leaf from the “Self Help and Actualisation Movement,” or as I like to call it, “SHAM”—the path to success is:
ONENESS…
Normally the first interaction you have with any vendor is through the sales team.
Sometimes the interaction is like this…
Over-promise…Get the deal…Under-quote…Under-resource…Under-deliver
At Kinetic Data, we try to make sure that we do not do that.
At the heart of achieving this is ONENESS between the client and Kinetic Data.
INITIAL REQUIREMENTS
Without clearly stated initial requirements everyone is working in a fog of doubt and uncertainty.
Vendors build-in large buffers for this uncertainty and often still under-quote for the project.
Once you have decided on a vendor for your project, work with the internal and vendor teams to:
DEFINE AND REFINE THE REAL REQUIREMENTS
Things to consider when doing this:
- You may not have all the information; consult widely with ALL stake-holders.
- There is only piece of clothing where “ONE-SIZE-FITS-ALL”—a straight-jacket.
- Trying to combine features of different offerings is rarely a success.
- Just because it can be done, does not mean it should be done.
- It may be a solution—but is it practical?
There is a reason why you are initiating this project, and it normally not just to:
- Replicate the existing application
- Change the appearance slightly
- Bolt-on some new functionality
- Get a more powerful application but restrict it to the old limitations
A successful project should deliver improvement. Not repackage the status quo!
To achieve this, all the parties have to be able to be flexible and willing to change expectations and requirements to deliver the BEST solution within budget and on time.
TIMING, EFFORT and BUDGET
Be realistic. Rome was not built in a day.
If you have been set firm dates and budget to deliver, then make sure that the requirements are aligned.
LISTEN
We are now in partnership with you to deliver SUCCESS.
It is not a battle between two sides—one trying to get more than agreed and the other trying to do less.
Remember that in a difference of approach, the consultant will advise on the best solution, but at the end of the day—if the client wants it, we will build it.
DELIVERY
So we now have a project that has REAL, WELL DEFINED and ACHIEVABLE requirements.
So, let’s stick with them when we develop the SOW and during the delivery period.
Tacking on new requirements while development is going on does not work. It adds to costs and delays.
Importantly, it just shows that the requirements gathering was a failure.
Finally, remember the ultimate measure of success is the satisfaction of your users.
Cassy Lueneburg
