Ten Top Tips to Deliver a Successful PI AF Project (Part 2)

By Steve Taylor, Principal Systems Engineer at ITI Group

In part one of this two-part series, Steve used the entertaining analogy of video games to explain some of the key strategies needed to ‘win’ at the PI AF project ‘game’. If you’ve not read it yet, you can find it here.

PI AF Projects are often challenging because the equipment and plants they are built to monitor are themselves complex. The knowledge and data to model them exists somewhere, but it doesn’t yet exist in one place, and must be gathered, assembled and checked.

PI AF is one of the most mature and versatile analytics frameworks on the planet: a good project pays its dividends handsomely. Some customers cite 50x returns on investment by building and scaling out PI AF Analytics, saving millions of pounds per year from just one or two sites. The value is proven, and it is tantalising: that’s why people often ask us how to do it successfully.

Back in April we considered our first 5 tips, themed around strategy gaming:

1. Choose your Hero
2. Refine your Core Strategy
3. Slay the right Dragon
4. Build a well-rounded Team
5. Don’t skip to the final boss

This month, we round off the list with our final 5, but this time considering *dangers* to avoid.

Recently, I delivered a Tech Talk for the Institute of Measurement & Control, examining how to successfully scale digital projects: this was a key point – and the rightful mirror of Top Tip #1 – failed user adoption is the most common cause of project failure.

Digital projects may be completed on time, under budget and be signed off completely, and yet still be utter failures. They become that new gadget which goes into the loft or shed and is forgotten – forever. You might even buy or build another one, forgetting the first one altogether.

This is nothing new, and ties back to the first six points from the Agile Manifesto, which I shall summarise:

1. Our highest priority is to satisfy the customer.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently.
4. Developers and end users must work together daily.
5. Build projects around motivated individuals.
6. Prioritise face-to-face conversation.

Engage users early, engage them regularly, and build a good relationship until you’re done. Along the way, ponder how to build and deliver new features in a way that foster user engagement.

Each of these points deserves more thought, but the bottom line is that Agile processes tend to demonstrate a better overall success rate because they focus on customer satisfaction rather than “finishing the project”.

PI AF projects thrive on scale – it’s the secret sauce to maximising ROI. But crossing that bridge from a Proof of Concept to a large scale project can be challenging. Large projects can get stuck – failing to make meaningful progress for weeks or months at a time… some basic assumption of the project has proven untrue, and the whole thing slows down.

Why do Digital Projects lose momentum? Let’s take three common reasons:

• Scope/deliverables are unclear
  Indecision kills projects. Somebody needs to set the path, know what ‘good’ looks like, and unblock the team. This could be the Hero, Project Manager, Business Analyst or lead engineer. “Where there is no vision, the people perish” – Proverbs 29:18

• The team’s too big
  Did you know big teams can deliver too fast? Every business has an ebb and flow: when a project moves too quickly, it wastes time and money. Team members run out of work, and efficiency drops. Stuff gets built, some of it is wrong and needs remediation, and nobody realises it until five weeks later when the users catch up with the changes: nightmare.
• The team is under-skilled
  When outsourcing PI AF and PI Vision development, weigh carefully who will build it, and who will supervise them: ensure they really know what they’re doing. I have seen six and seven-figure PI AF projects tossed over the line like hand grenades by teams that knew shockingly little about the PI System, and even less about the business context. They “followed the requirements” and didn’t ask the right questions at the right time. These projects failed and required major remediation.

To keep moving fast, have a clear vision and the right-sized / right-skilled team.

PI Vision has limitations as a product, but you’ve got to give it a heck of a lot of credit for its versatility and flexibility. Too often this versatility is simply ignored, and teams build screens for the sake of building screens: a pump here, a chart there… job done.

In terms of ‘Return on Investment’, this approach is not the best. The PI Vision Administration has reports showing display usage, and often large projects end up with >50% of displays receiving little to no traffic. Users either don’t need them, or can’t find them.

I’d love to write a bigger blog on this one, but here are a few visualisation tips:

1. Ensure each display has a purpose – who is using it? Why? What are they trying to do?
2. Ensure each display has only the data its users need, and isn’t crowded.
3. Ensure each display includes all the features your user will need – do they need to input data to the PI System, log issues, or visualise data from other systems?
4. Ensure each display has links – where do you want to go next? How do you get there?
5. Ensure each display follows standards – a consistent look and feel for users, with conventions that implement modern UX principles to reduce Human Factor risks.

Don’t build screens for the sake of screens – plan your UX philosophy beforehand.

Every Project needs a well-thought-out deployment strategy: this is a make-or-break point for large projects. Healthy, living, breathing PI AF models may contain rich intertwined relationships between all sorts of data – inherited, static, real-time, and manual. Taking the wrong approach plays havoc with the model, and may not be noticed until it is too late.

When developers have only done one or two PI AF projects before, there’s a risk they just follow whatever worked on the last project, without thinking twice – I’ve seen this play out a few times.

Here are ten typical questions which you should know the answer to:

1. How many environments do you need? Prod? Test? Dev? How are they managed? Which objects are and aren’t synced between environments?
2. Will you do targeted deployments or aim to update the entire database every time?
3. What kind of reviews do you perform on Analytics before deploying them to Production, to ensure accuracy and server risk mitigation?
4. How do you ensure that you don’t change things you don’t mean to? Does this match your approach to inheritance?
5. Are security, UOMs and Contacts the same between the source and target environments – and managed correctly?
6. How do you backfill your calculations in the right order, and to when?
7. What does a deployment pack involve? Which tools will you use to handle deployment packs – XML, PI Builder, PowerShell or even command-line tools?
8. How does your strategy affect how you deploy PI Vision displays?
9. What kind of automation can you use to streamline the process?
10. What kind of change management process do you need to follow?

Large projects spend weeks delineating their deployment philosophy, and then months refining their process. I’ve helped teams optimise this process, built tools to enhance them, and mitigated risks they were facing. This is a key point to get right – if this is a challenging area for your team, I’d love to help!

Ensure your deployment plan is fit-for-purpose for your specific project and environment.

In software, maintenance backlogs go by another name – technical debt. Best practice software development is all about reducing the ongoing burden and costs of creating and maintaining digital products. The high degree of interconnectedness within the PI System makes this a key risk for PI AF Projects.

In the worst case I have seen, a seven-figure PI AF project had to be written off because the generic IT Services company which designed the model never considered how it would be maintained – this was left to the customer, who simply did not have time for this. The project just became more and more outdated until it did more harm than good to keep it around.

In most cases, the answer to this risk is to follow best practices right from the design phase: templatize; automate; manage UOMs; manage security; have a sensible deployment strategy; manage your non-production environment well. Through all stages, working to reduce your level of technical debt to ensure your project stands the test of time.

Ensure you include senior developers for whom it is not their first rodeo; they look at design choices and ask “but how do you maintain that?” because they’ve seen it all before.

Taking both parts of this series together, there are ten things to do now if you want to deliver a successful PI AF Project:

• Choose your hero, refine your core strategy, and slay the right dragon.
• Build a well-rounded team to get the job done, and don’t skip to the final boss.
• Beware failed user adoption, don’t lose momentum, and avoid wasteful visuals.
• Plan your strategy to avoid deployment purgatory, and take care that the finished product doesn’t leave you in maintenance hell.

Do these things well, and you’re on track for an outstanding PI AF project. Don’t forget to capture the value that your project delivers for the business, especially in early life. The earlier you demonstrate real savings, the easier it is to secure the support you need to finish the job.

If you’ve made it this far, thanks for your time. At ITI Group we love PI AF Projects, and we would be delighted to help you get your next one up and running.