Paul Ritchie,
As a CIO, you have either made – or heard – recommendations to create an IT project management office. Perhaps you have implemented one, and your department is reaping the benefits of project planning, monitoring, and controlling. IT delivers its projects on time, on budget, and to spec. Congratulations! You and your IT PMO have put the foundation of consistent innovation in place.
Nevertheless, it is no more than a foundation. A PMO must transform its approach to stakeholders or it will not take full advantage of the improvements it fostered. A mature PMO contains the seeds of its own irrelevance:
An IT PMO composed of PM thought leaders executes a PM improvement program that delivers methodology, training, tools, and change management initiatives to its stakeholders (e.g., infrastructure, application, and business relationship teams).
Those stakeholders [largely] adopt those initiatives and transform their project operations in significant and measurable ways.
This transformation creates a new set of PM thought leaders, who often surpass the knowledge and hands-on experience of the original IT PMO.
The business problem has reversed; the IT PMO now becomes the organization that needs to change to reflect the new reality. Deliverables that were relevant in moving from low maturity processes no longer work with a more sophisticated audience. This issue is compounded by the difficulty in recognizing the changed environment. Who wants to admit that he/she is no longer automatically at the vanguard of knowledge?
In other words, the challenge for a successful enterprise PMO is: “Who will change the change agents?”
As your stakeholders improve their adoption and execution of standard processes, they naturally want to innovate to meet the needs of their particular commercial and project environments. For example, one function may need more soft skills training; another unit may need to incorporate agile concepts in its methodology, while another needs to better manage diverse and geographically dispersed project teams. An IT PMO must take an active and explicit role in integrating such process improvements into its own portfolio. Otherwise, its work product and services become marginalized, or even irrelevant.
“R&D needs more powerful machines than most users, its engineers have
So where should we go next? While your lessons learned will depend upon where you, your department, and your business are today, I have a few suggestions about where to start looking for opportunities to “learn and adapt.” The first place to look is at the very lifeblood of a biotech business: innovation.
Nearly every IT department struggles with its working relationship with research and development. From desktop services, to application development, most IT departments I have worked in cannot quite satisfy their research colleagues. R&D needs more powerful machines than most users, its engineers have high-maintenance and one-off applications on those machines, and IT is consistently surprised by new demands from hither to unknown new product development initiatives.
This last problem – poor or intermittent visibility into the innovation pipeline is where an IT PMO can help. It does so not by forcing compliance with a formal reporting edict, but by helping R&D with its PMO challenges.
An example is a portfolio planning initiative life sciences IT PMO co-led with its R&D PMO counterpart. We worked together on planning, budgeting, selling, and the implementing the process and technology. This collaboration laid the path for a sustained business relationship with R&D. Now that, we had regular contact, the IT PMO would be more plugged into its counterpart’s innovation portfolio planning. This notion of a managing concept or master plan—a master architecture, if you will—will in turn let you plan the foundational elements IT needs to stay aligned with your organization’s vanguard function.
This first suggestion about R&D points to other potential synergies across the organization. For example, PMOs can start to work with your compliance department on streamlining its audit procedures and embed proper practice into your department’s way of working. I have found that adherence to 21 CFR Part 11 does not need a whole new layer of “compliance-only” activities on top of regular IT work. Frankly, most requirements of FDA validation are simply good practice. Properly designed change process and technology will make computer system validation something that happens as your teams deliver value, not a separate chore. Once your PMO is a partner with compliance and audit, these synergies emerge with consistent attention and effort.
Finally, new methodology approaches can make IT more nimble by shortening project cycle times and reducing unnecessary work. Even if you do not have much experience with agile or iterative development approaches, your PMO can start to introduce the concept in key areas of your project lifecycle.
In my experience, the test, defect, and fix cycle is a quick win. Too often, a traditional “waterfall” development shop treats testing just like the initial requirements-to-development phase: throw the defects over the wall, next developers will fix them, then the process or activity in question is tested again. It is relatively simple to use a method like SCRUM – which enforces daily checkpoints and regular delivery of usable work product – to drive shorter, more predictable test cycles. In addition, I have found that an unexpected benefit of agile is surer acceptance of the deliverables my team’s projects create. Other functions have been involved in verifying your break/fixes all along; therefore, they are less likely to hold back when you ask them to sign on the dotted line.
I hope that these three ideas for moving your PMO to the next level – understanding that the PMO must continuously evolve, using the PMO to align with your innovation centers, and adapting agile practices –help you deliver more value more quickly.
Check Out : Top Biotech Startups
