In this article, we continue our discussion into the process of building out a complete Project Analytics capability for your major projects initiatives.
Last week, we explored the engineering architecture required for a modern Project Analytics capability. This week, we look at how to create a roadmap from your Project Analytics pilot into a production-ready solution that is fit for the future.
Introducing the Phases of Project Analytics Deployment
Phase 1: Data Architecture Conception / Proof of Viability
We covered most of this phase in last week’s article that unpacked the topic of data engineering for Project Analytics.
Key milestones in phase 1 are to determine the availability of the data you require, and the viability of the architecture you have in mind for your Project Analytics initiative.
Coming out of this phase should be a roadmap of how your solution will be built and an ‘illustrator’ that supports any internal business case activity.
Phase 2: Building the Core Platform
During this phase, you will begin to leverage your earlier data engineering exploration to increase the level of data ‘ingestion’ into your Project Analytics platform. The goal here is to build a live demonstrator that possesses enough functionality to deliver value to the business.
For example, in phase 2 you’re looking to demonstrate:
Live connectivity to core systems:
You’re looking to demonstrate that your analytics platform can pull in operational data, in an acceptable timeframe, and translate this live data into some form of insight
Data organisation/productionisation:
As discussed earlier in this series, a lot of major projects reporting in the past has required substantial manual cleansing and manipulation of the data before it’s deemed ‘fit for purpose’ enough to hand over to senior management.
In phase 2, you’ll start letting go of those manual processes and start relying on the data engineering platform you created in Phase 1 to better organise and manipulate the data in a more automated fashion. You may still be some way off a fully operational, signed off solution, but your team should be putting in the right processes to ensure a more predictable result from the inbound operational data.
Blocker removal: At this phase of the journey, it’s not uncommon to start experiencing some blockers to your progress, these typically fall into the following categories:
- Organisational blockers
- Process blockers
- Data blockers
- IT blockers
Building out a Project Analytics capability requires a great deal of change; you’ll need to accept this and plan appropriately. For example, this may be the first time your organisation gets to agree on simple classifications and definitions of some key data terms. You’ll soon realise the importance of building a data governance strategy to set up data stewardship and accountabilities within major projects. The quality of your analytics will be greatly improved if each department comes to an agreement on the most critical data within the business.
Quite often, you’ll begin to shine a light on longstanding data quality issues that need addressing as you build out your analytics capability. This is to be expected, so don’t shy away from making organisational, process, data and IT recommendations that improve the final outcome of your analytics reporting requirements.
Phase 3: Production Build
In phase 2, you’ve been mostly building out a ‘beta’ version of the core platform, but in phase 3, you’re going to start extending your analytics platform to support production capabilities.
For example, you’ll be introducing different environments (e.g. Development/QA/Production) to coordinate regular cycles of production-ready software releases.
One challenge at this phase will be managing the wave of inflated expectations. What you’ve created by this point will be far more advanced than previous project reports so you’ll need to ensure you have a communications plan and clear roadmap for engaging the users and stakeholders.
You’ll also need to make it clear in those communications that, due to increased automation, there may be the occasional poor quality result coming through into the final analysis. This is to be expected as you scale up your production operation. The key is to eliminate the root-cause of any data defects, and follow up with some transparent discussions around what the users and stakeholders can expect from the data as it transitions through these early ‘growing pains’ of your production process.
Quite often, occasional reporting issues are not always highlighting technical issues, but required changes in culture. With the added emphasis on data automation, your project staff will need to get accustomed to improving their data entry and project data quality.
Other data challenges will become noticeable as your production environment ingests more data, particularly as you ‘widen the net’ for inbound data sources. A common issue will be the ‘single version of the truth’ problem that invariably arises when different applications, or even different departments, hold conflicting records. For example, it’s common for different systems to have differing project baseline data, for a variety of reasons.
At the end of phase 3, you would expect your production environment to be an ‘enterprise grade’ system, meeting whatever relevant IT, security, data protection and data governance policies and controls your organisation may impose.
Finally, phase 3 is where you will typically have enough resource and stability in your platform to start exploring any use cases for Artificial Intelligence and Machine Learning.
Phase 4: Transition Back to Business
At this phase, you’ll be looking to create a Business as Usual (BAU) scenario with your Project Analytics capability. Don’t underestimate the effort required to fully train and orientate the business on their obligations for taking over the solution.
Phase 4 is where you’ll be in a good position to integrate with other large data initiatives, if they exist. By this point you’ve already created a robust data platform so you can expose your data to these bigger programs as just another source of quality data, but be sure to apply data quality controls/tests for the data you supply. Likewise, you want to be checking for data quality on any inbound data you receive from other data initiatives.
During this phase, you can also start to realise the bigger benefits of Project Analytics by ‘democratising’ your data to project staff in need of good quality data and reporting insights. This project analysis ‘LEGO® set’ creates the building blocks of a self-service business intelligence capability, complete with a clean set of unified project data.
Finally, project staff can swap their spreadsheets and hours of manual data wrangling, for a trusted and fully operational project analytics environment.
Next Steps
In the final article of this series, we’ll recap on all the steps you will have travelled so far, and outline how all of the typical Project Analytics use cases will come together, and who will benefit the most.
If you have any questions about any of the techniques we have discussed in this series, feel free to get in touch for more information.
