I remember when I first went into sales there were all sorts of things that we learned. But ultimately it all boils down to results. The same is in public companies. People hold their collective breath until results come out and then judge their actions accoridingly not about the various achievements, progress etc that is left to the analysts and Warren Buffet – said somewhat tongue in cheek.
For those of us who have come from IT Consulting it is often very different. We are often singularly focused on a deliverable. That deliverable needs to be done for this much money in this much time and here is the design document we are building to – the rest is periferal.
Time to Change
Focus on the results. Why because that is what matters most to the end consumer of our services, they just use the design document and deliverables as a checkpoint for ease of evaluation. The real value is in the business result. Let’s take an example that is near and dear to us at Project X.
We have a client in the Enterprise Data Warehouse arena. The marketing group has decided that they need to be able to understand something about their customer. So they go to IT, IT goes to the Data Warehouse group who then called us and asked us to add some source data into the data warehouse. See the disconnect. Maybe you see the obviouse one, but how about the difference in the way we all view finished.
The business will see it completed when they have the piece of business information that they looked for so that they can drive the business result. That may have been done early in the IT phases of the project, but it needs to follow process and go into production, etc. What if we turned the problem/solution on it’s ear and did this.
Get the result by putting the data into a holding place in the data warehouse and then worrying about the IT stuff till later. I am not giving all the details here so I appolagize but you do not always need something put into IT’s view of production to drive the result. If you got the data into the hands of the user in 3-10 days you will have driven the results in a rapid fashion. It does not mean we are finished from an IT point of view. That isn’t until the deliverable is put into production and that often is a lengthy process and is often not relevent to the business user but is to IT.
I like your idea of delivering a results rapidly while continuing to build the long term solid structure. I agree with the idea of a prototype if it is a working prototype so that the customer can use it while you are building the production one.
Often you will find the quick bulid which meets the spec does not meet the clients need. You can the rapidly make the modifications to meet the need. I have several examples where we saved the client alot of money by delivering a production prototype quickly.
One key item is it helps the organization develop the ability to adapt to the new system quickly. New systems require client to change things as well and learn new things. A good open dialogue with a cross functional team really helps.
Good idea in theory. Wouldn’t it be great to give the business reports in a few days rather than the two to four weeks of analysis, design, build, test and delivery. In practice a shortcut ends becoming more and more of a problem over time as the business continue to ask for data this way and it grows too large to manage.
So I would only do this if it were a short term solution, kind of a prototype of what the reports will look like once the data is properly loaded.
It’s All About the Results
nice..