My role at OptimalBI has three areas I concentrate on:
- Solution Delivery
As the founder and part owner of OptimalBI, when I make a promise to a customer on what we will do to add value to their business, I am ultimately responsible for making sure we deliver (of course we have a great team beside me that makes sure we deliver)
- Architecture and Strategy advice
I am often engaged by customers to assist in developing Business Intelligence related strategies or architectures, everything from Master Data Management strategies to architecting an Oracle ODI and Golden Gate based data warehouse.
I am lucky enough to get a bit of time to focus on Innovation, from researching where the BI markets is going, what products are going to revolutionise the BI capabilities within our customers or what other areas of delivering services based value we should be investing in.
When engaging in projects from either a delivery or strategy/architecture point of view I find that I need to quickly get up-to speed on what the project is about, where it is at and where it is going.
I often find that as I talk to different members of the project from the steering committee members (you do have a steering committee for your project right?), key/management user group members, project manager, subject matter experts and project members, I often get different opinions on what tasks are underway and what are planned.
Of course there is typically a scope document and a project plan (and often a Project Initiation Document) but when talking to different people you often get different opinions on what each task or deliverable is. This is not an insurmountable issue and can be easily managed via good communication throughout the project.
The one thing that for me is the most important to understand is what tasks are required to be performed, by who and by when. Without this understanding there is a high chance that the project won’t be completed ontime and therefore won’t be on budget.
Initially I used to always ask the what question first,I.e what is this tasking achieving or delivering, then when will it be delivered and then by whom. The issue with this approach was I often got the view of the what from a project manager or team lead that markedly differed with the expectations of the what from the person actually responsible for undertaking the task.
So now we do it this way:
First ask who is doing the task then ask that person the what and the when. Validate their answers with the team lead or project manager to make sure we are all on the same page.
Try it, you will be surprised at how often you will not actually get an answer to the who!
And that raises a important note, the who is a person, not or a team or a business unit, or a supplier.
So a long post for a simple idea, but a simple idea that saves us a lot of time and results in a higher rate of successful projects.