I have been wondering of late – what a “Quick Win” implies and means. From my experience with BI projects, very often because of fairly uneducated target consumers and fierce competition, companies deliver quick and dirty solutions, hoping to attract attention and then sell more services. This practice is often referred to as a “Quick Win”. Of course, the actual intention is not bad, but when poorly executed it firstly wastes clients’ money and time and then also discourages them from pursuing a BI solution any further. In the case of a failure another term – a “Quick Loss” is more appropriate but never used.
So, what determines the outcome?
Managing the scope is absolutely essential in a Quick Win scenario. We must convince the client that all the advanced functionality can be safely pushed back to the next full-blown release when we would have the time and money to build it properly. If we extend our Quick Win to build Dynamic Dimension Security, partition our cube, clean up the data, build dimension managing capabilities (MDS comes to mind), etc. we will most likely fail or at least jeopardise our chances of success. In this first crucial phase we need to concentrate on the core – building simple and robust system. Instead of having the usual scope creep, we should actually try to push for the opposite – scope cuts. Of course, this has to be carefully balanced with the actual need as cutting too much will leave us with an unusable result.
In my opinion, if we deliver a poor quality solution it will fail and no attempts to resuscitate it later would have any decent chance of success. So, when we are scoping out our project we must make sure we have time to build it well. Shortcuts would quite likely make us scrap it altogether at a later point of time and then rebuild it properly. Also, if we build an OLAP solution which is slow and buggy, we would hardly be able to convince our client that the next phase of the project will be any better.
3. Analysis and Design
Yes, it is a Quick Win and yes, it is a BI solution, but even these (contrary to some opinions) do need analysis and design. Spending a bit of time with the business users, the source system and with the server engineers can greatly improve the development experience. Without a design phase, it is hard to maintain a strict scope and attain high quality. A brief design document helps with remembering why we have done something the way we have and decoupling us (as developers) from the solution.
4. Task Management
I am not a project manager. However, when alone on a small project I find it very useful to track my progress and objectives by building a basic spreadsheet showing Tasks, Description, Time Allocated, etc. This way I can easily comprehend and explain how my development is going, and ask for more time before I hit a deadline if required. Also, a task sheet helps me to switch between tasks, or allocate them to other developers.
5. Managing Client Expectations
I have heard this phrase many times before, and it has usually been misused. Managing client expectations does not actually mean lying to the clients, neither it means promising too much. In my opinion, managing client expectations means exactly what it sounds like – don’t make your client too excited with what you cannot deliver and make them expect exactly what you can. It is good to keep the clients happy and optimistic for the future, but making them enthusiastic and then crushing their enthusiasm with a dud solution is unprofessional.
This issue has been haunting me for a while. I have definitely not exhausted the topic and I am sure that many developers can add to this list their own thoughts, but I just hope I can spare some trouble or offer some hints for the less experienced readers of this blog.