One of our customers has a really interesting set of projects. Each one individually doesn't have a lot of sizzle to it - just enough ROI to justify doing the project. But collectively, these projects are the backbone of collecting a whole new segment of data about their business. This data could be mined to produce transformational changes in their business processes, or just tactical changes. It is actionable data. That's pretty exciting. I hope we'll continue to have an opportunity to work with them and work out ways to take advantage of this data.
But I think the key thing is for a big project like this to succeed, it can't be too big. The law of large numbers can grind you down, especially on cross-functional, cross-department, cross-technology-competency-center teams. If the project is too large, too much time is spent coordinating and not enough time doing. To address that size/scale problem, we've broken the project into separately addressable projects that tie together with the data that we're capturing. I think the customer is being really wise to break it down like this too.
This is a general principle that can be applied to most process projects - find logical touch points or boundaries where you can interface/integrate with the existing process and define your project accordingly around that bite-size piece. Subsequent projects can build on that first success, and leverage those interfaces. This also helps establish a pattern of successful deployments. Like any team, having a pattern of success tends to keep people motivated and on-task, and makes it more likely that future projects with ROI will be funded.
We're about to push the first project live with this customer, and it feels good to be almost done, and get this into production to start earning that Return on the Investment for them. And then we get to move on to the next bite-sized piece, which is a really interesting bite, with a well-defined hand-off to existing systems in their enterprise.