A project is typically defined as a discrete activity with a defined schedule and budget that has been set in motion to achieve a specific set of objectives. But, in today’s integrated world, programs, development and operations can (and should!) heavily overlap. Staff are typically multi-disciplinary – wearing many “hats” – and a well-formed project team will often draw from different departments within an organization. Systems share not only data, but require processes that span functional areas. There simply is nothing discrete about it.
This presents a host of challenges for today’s project manager. Our mandate may be to replace one node in a connected web of systems. Our projects have goals to transform business processes even where those processes weave in and out of the target systems. And, building bridges to legacy architecture are unlikely to ever realize their value if once we replace one side of the bridge our next project will be to replace the other.
This post provides a few best practices to consider if you are a project manager tasked with advancing a “discretely integrated” project.
All peripheral applications are risks to plan for and monitor.
As part of risk identification, I would suggest the moderator stand in front of a wide board and place the system you are replacing at the center. Then draw every application that is currently integrated, will be integrated, shares data or is used by a business unit impacted by the system you are replacing. Then consider how each application has the potential to present risks to schedule, budget or scope.
For example, if your project is tasked with replacing a fundraising system you will have your general ledger as one of the nodes on the board. What are the integration expectations relevant to the GL-posting process? Which processes will move between the systems (ex. gift processing > reconciliation > adjustment)? What is the current state of your GL (ex. Nearing replacement, recently deployed, etc.). And what are the risks associated with this application based on our understanding?
Anticipate integration life-span and set cost accordingly.
Integration, even with today’s fairly open systems, is typically a major cost. It is not uncommon for organizations to spend hundreds of thousands of dollars integrating their online systems with their CRM (yes, even those CRMs that are in the cloud – and therefore, technically also online). As we plan integration, it is important to ask ourselves how long is this integration expected to last? How much business value will we get from it? And, how much have we budgeted for it?
An organization that plans to sunset their online system in 3 years will need to see at least $100,000 in business value if they hope to see a return on $300,000 of integration budget. The math is simple, though can be surprisingly difficult to articulate. After all, isn’t the expectation of our constituents a unified donor experience? Are we not likely to see a dividend from multi-channel communications that cannot be easily quantified? (Answer: yes – probably).
The point of the exercise is not to silo your system as an outcome of your project. Rather, we should consider cost and return. And, we should consider if there is not a near-term viable solution that can bring cost down and balance anticipated business value.
One of the more common examples is evaluating real-time integration for daily integration. An organization that is looking for immediate flow of data between online/engagement systems and a back-end fundraising system is an organization that has placed a high premium on unified data – and a unified customer experience. This organization is also likely going to absorb a high cost for real-time, automated integration – as a robust system of logic will need to be created and maintained. And system performance as well as impact on data integrity will need to be fully understood and planned for.
Rather than go the route of real-time, an organization should ask themselves if this cost directly creates business value. By comparison, it is worth exploring if a daily sync of information, without the same degree of automation overhead, would provide comparable business value at a fraction of the cost.
Build peripheral project teams into your project plans.
Peripheral projects that will eventual converge or directly overlap with your project should be fully integrated in your project management plan. I would suggest taking this a step further and also build communication activity around those seemingly disconnected projects.
On a recent project, the general ledger was being upgraded in parallel to a fundraising system project I was overseeing. The integration (e.g. manual export/import process) is the one obvious area of overlap. But, stepping back and looking at it – the GL-upgrade PM is sharing many of the staff resources that are managing gifts in the fundraising system as well as those responsible for the posting process. There is also active discussion about process improvements that I believe would require not only transforming those processes in the fundraising system – but also likely require transforming those processes into general ledger processes (a system clearly outside our team’s purview).
Early conversations with the GL-Upgrade PM established a monthly meeting to talk about go-live dates and general coordination. These conversations are now mushrooming into business process transformation and resource-sharing. This type of cross-project collaboration could fall to a Project Management Office (or PMO), though few organizations have the capacity to build and sustain a PMO.
As previously noted, this is a classic example of where a peripheral application has both a dependency on us meeting our business objectives while also presenting a clear risk to scope (and, soon enough – schedule and budget). But, the early risk identification and communication work helped identify and begin to plan for these issues early in the project.
Ensure cross-functional governance structures are in place.
A recurring theme is the importance of understanding the boundaries of a project while also recognizing that those boundaries quickly move – or disappear altogether. New systems and business processes are likely to exceed the definition of a project as a “discrete” activity. A PM’s best response is through an effective, cross-functional governance structure.
As boundaries get crossed or decisions begin to have farther reaching consequences, escalating through a governance body is your best chance to see resolution. Additional detail on establishing a governance structure can be found here – http://www.craftsmantech.com/2015/08/21/a-governance-model-for-large-projects/.
Conclusions
A project must have a beginning and end – and be backed up by a discrete statement of work. However, few systems projects occur in isolation. More often than not, a CRM or fundraising system refers to a collection of interdependent tools, processes and people. Understanding and appreciating the system and risks presented by those applications or projects running parallel is critical to success. Weighing value for any investments in temporary solutions will help ensure your project’s business case is viable. And, having a means to escalate cross-functional or cross-departmental needs – often outside the mandate of your project – are your best bet for ensuring your project ultimately moves forward despite the integrated world in which you work.