For large organizations it seems that as technology grows more and more integrated, IT related projects become more complex and thus longer in overall duration. There is no doubt the rise in cloud/SaaS solutions has exacerbated this increase in overall IT project complexity. I’ve written on the impact of cloud in this manner prior here. Gone are the days of a large corporate IT shop having a project manager engage the same three or four familiar delivery stakeholders and with little outside involvement, execute the project beginning to end. This increase in technical integration means a project manager can no longer count on those three or four stakeholders having the cross systems knowledge and technical systems access to implement changes as crisply with few artifacts as to what the project has done/is doing/when/etc.
To help illustrate this evolving shift, consider the following hypothetical large corporate IT conversation:
PM: “Welcome everyone to the FlimFlam upgrade project’s twentieth weekly status meeting and a special welcome to Jim who is joining to help sort out all the changes that impact others outside of our core team.”
<General welcoming gestures and verbal niceties ensue>
Jim: “Ok, is there any diagram that captures all the flows of data in and out of the current FlimFlam system?”
Core Team: “Um, no, we just know them from working on FlimFlam for the last five years.”
Jim: “Um, ok, have you mapped out what new features of the upgrade are turned on compared to off and who would be affected? Or say, documented the link between the features and business requirements?”
Core Team: “Well, not documented, but we know HR wants the real-time instead of batch interaction and Operations wants better reports. But HR outsourced last year to a cloud provider and we have no idea what Operations is doing …”
Jim: <thinking to himself> “… oh boy, good people, but this project is looking like a train wreck already …”
Clearly a “business as usual” approach to this upgrade isn’t going to work any more.
In the past, with so few stakeholders having comprehensive access to the silo-ed systems impacted by these types of changes, the need for easy to digest transparency into what changes were going to happen when and how was not critical. Sometimes the only visibility to what such a small project team was doing was in the production change management review and approval process:
Change Control Board: “Ok, next up is change record number 72,578 which reads ‘Enable the employee web portal to support the time off calendar’. Anyone here have any concerns with this change? Hearing none, approved. Next on the list …
Today’s Problem: IT systems are too interconnected for lack of project transparency to change
Sounds like 72,578 is a simple change that an HR delivery team of the past could have easily implemented without much cross team impact. But today, that example time off calendar may need to interact with the HR system to record those time off days against how many the employee actually has as part of their compensation package. There probably is a need to support some management approval work-flow. Plus, there are probably other work scheduling systems and PMO resource planning tools that need a feed of that data in order to accurately support their user base. There is probably some single sign on/web access management technology involved to support all employees accessing the web portal, some central provisioning system to handle access plus some remote access needs to support today’s mobile workforce. It is probably safe to assume that some of those integrated systems are in-house and some are cloud/SaaS or a mix of all of the above.
Additionally, with matrix-ed internal and external project resources with contracted and off-shore delivery coupled with the “cloud” vendor resource engagement model, a simple change could have a variety of stakeholders in need of agreement on what is changing when, etc.
Thus, hopefully I’ve convinced you that something as simple as a web portal for employee time off entry can involve a number of different internal and external teams and systems that all need to coordinate changes to support the business objectives of this example project.
So how does this all drive the need for “transparency”? Isn’t this just a basic PMO 101 issue of dependency management and cross project impacts?
Yes and No
The project team needs to produce deliverables that don’t just get the core team in agreement to pass the next quality gate in the project life-cycle (never to be revised again); the project team needs to produce deliverables that outline, at a high-level, the following basic project elements:
- Scope of the project in a sentence or two
- What is changing from present to future state
- Who is impacted by the change (and have they been engaged)
- Lastly, what isn’t in scope (that a non-core stakeholder might assume is in scope)
… for non-core stakeholders to easily digest and understand … and update the material frequently to have at the ready anytime it might be needed.
Besides an effective communications vehicle, another subtle yet important aspect to this deliverable is its ability to build confidence in the effective management of your project in outside stakeholders. This confidence can lead to senior management getting the impression the project is “under control” and move on to another project for increased scrutiny rather than assigning all kinds of ancillary people to dig into your project to figure out why they don’t have that “under control” feeling.
Stated another way, large corporate IT projects today need to adopt a bit of “program management”, specifically, some of the enterprise reporting themes. A Gantt chart (which I’ve extolled the benefits of before here) isn’t the end-all-be-all here. A slide deck that contains a few slides covering these topics with lots of pictures and drawings where ever possible would be more effective in serving this communication need.
So if you are a project sponsor or a project manager, consider having a communication deliverable that is actively maintained, even if your PMO PLC doesn’t explicitly call for one, to provide simple and easy to digest transparency into key aspects of your project at the ready at all