Breaking down information silos - Part 3

Hope that you like Part 1 and 2. Part 3, the conclusion to my post, is about lessons learned.

We adopt the Scrum Framework at Vorsite. Scrum, in my opinion, works particularly well for high risk projects. Customers see deployable components by the end of every 30-day sprint. Yes, we do not know for sure if we can deliver everything we promise since we can only make the best decision base on what we know at a specific point in time. But that does not mean that we under-deliver either since someone will always be pushing the envelope.

Before we start development work, it’s my job to communicate a set of clearly defined end of sprint deliverables. These goals are signed off by all stakeholders and team members. By the end of the 30 days, we measure and reassess where we are with the overall project goal. Mistakes are not as costly since we get early validation/ feedback and have the ability to take immediate actions to do the necessary course correction in the subsequent sprint(s). And from sprint to sprint, project sponsors see visible progress. I secretly suspect that was the reason why Vorsite was approached to take a stab at surfacing the data. Put yourself in the decision makers’ shoes: can you still confidently fund a project if, after 2 years, you still do not see nor use any deployable components? I know it depends on the project scope but you know what I mean.

Another tool I find effective in communicating requirements and managing expectation is to conduct mock up/wireframe review. I always use the most low-tech approach to avoid giving end users and management the misconception that everything is done. I either draw or use MS Paint (!) to cut and paste components to create mock up screens and then walk everybody through key scenarios. It’s a tedious process but you will be surprised how it helps. You, as well as your audience, will be given an opportunity to think things through. But life is of course full of curve balls. I still get surprised once in a while but in general, I get what I ask for and customers understand what they will be getting.

However, I did wish that I have a more diverse group of users for the wireframes review and had the opportunity to interview not just the super users (who are mainly Business Unit Managers) but perhaps a Profit Center responsible, a field agent and even a vendor who uses the tool. After all, these are the other key personas. Without any knowledge of their needs – how do we do a good job in making sure that the solution scales?

Having said that, time frame is always a constraint.

I was grateful the customers decided to keep direct data integration out of the picture. But on hind sight, perhaps we should invest a little more time in planning out data integration. The inability to automate data import will eventually jeopardize the project and that remains as a risk not sufficiently addressed. Also, in the perfect world, we really should establish a closer collaboration with the group who owned the OLAP cube. We are experts in hooking things up in SharePoint, while they are the experts in OLAP cube (and BI) - it really is a win-win situation for both.

In conclusion, this is a fun project. Started off chaotic but we did a good job in scoping the requirements and ultimately delivered a value-add solution. Someone once told me that if I did a perfect job, he doubt that I would learn anything next so I guess room for improvement is always an opportunity to make it even better!

Till the next project! Meanwhile, it’s time for a good glass of wine.