- Known problem / known solution – e.g. engineering problems like building a bridge. Such problems are suited to traditional project planning and management because, fundamentally, the goals don’t change and the methods required to reach those goals are known, tried and tested. To be sure, there will be operational dependencies and contingencies to contend with along the way, but no radical unknowns. The appropriate KPIs here are those commonly used for project management: percentage complete, on time, and on budget against tasks and milestones in the context of a plan.
- Known problem / unknown solution – e.g. many software projects. If the design can be specified upfront and is relatively stable then what remains unknown is the exact configuration of the working solution. The appropriate KPIs here are working lines of code, each of which gets the enterprise closer to its goal. Ries presents Agile software development as one way of managing this sort of enterprise.
- Unknown problem / unknown solution – e.g. online startups. Here the viability of the enterprise itself is radically uncertain. The search is on both sides of the commercial equation: for customers with needs and products to meet them. Constant experimentation is required to iterate different offerings in search of a paying customer base, and this needs to happen as efficiently, effectively and adaptively as possible. Why spend 6 months building something no one wants when you could have learned that lesson in 6 weeks? This is the Lean Startup sweet spot.
The essence of Lean Startup is “pivoting“. Assumptions are identified in risk order and successively either validated or invalidated via experiments, each of which is designed to produce a learning outcome. Each outcome marks a knowledge consolidation point which determines the direction of the next experiment. “Lean” means running these experiments as parsimoniously as possible in terms of both execution cost and outcome. Why build the perfect website when you can get a Minimum Viable Product up much faster to validate whether people will use it? Why build a website at all initially if you’ve not first run a Google AdWords campaign to see whether prospective customers can find your landing page via search and are willing to click through to it? The leaner you are, the more pivots you can execute and the more you learn.
One of the core contentions of Analyst First is that Business Analytics lives more in the type 3 domain than in type 1 or 2. As such our approach advocates:
- Accepting uncertainty, sometimes radical uncertainty.
- Treating learning as an outcome, often the primary and explicit outcome.
- Seeking validation where possible, as opposed to making ‘faith-based’ decisions.
About usAnalyst First is a new approach to analytics, where tools take a far less important place than the people who perform, manage, request and envision analytics, while analytics is seen as a non-repetitive, exploratory and creative process where the outcome is not known at the start, and only a fraction of efforts are expected to result in success. This is in contrast with a common perception of analytics as IT and process.
Tags in a CloudAIPIO analyst first Analyst First Chapters analytics analytics is not IT arms race environments big data business analytics business intelligence cargo cults collective forecasting commodity and open source tools complexity data decision automation decision support educated buyer EMC-greenplum forecasting HBR holy trinity human infrastructure incentives intelligence model of analytics investing in data lean startup literacy management culture MBAnalytics operational analytics organisational-political considerations Philip Russom Philip Tetlock prediction markets presales R Robin Hanson Strategic Analytics tacit data TDWI Tom Davenport uncertainty uneducated buyer vendors why analyst first