By Geoff Parker and Paul McTurk
Having worked on more than one hundred information system projects and programs over the last 20+ years, for lab-based organisations of all shapes and sizes, we know that people can sometimes confuse the two. It’s an easy mistake to make! However, there are very clear differences between a project and a program and, as we have demonstrated to our clients many times, handling each in the correct way can have a big impact on overall success.
Projects are typically well-defined, as they deliver a well-understood, specific goal or outcome, within a specified timeline: e.g: implementing a new information system or service within a laboratory. There is usually a distinct team and a clear route from start to completion.
A program involves doing things that deliver a strategy or initiative – or a number of strategy points or initiatives – and is less easy to define, compared to a project. For example, a program might be put in place to respond to a challenge such as: ‘We want to make the lab 30% more efficient.’ There might be (and usually are) projects underneath this, which could include ‘Specific enhancements to current information systems’, ‘Good lab practice training’, ‘Lab supply chain improvement’, etc. Programs can span several months, or even years, and therefore require strategic oversight, a lot of iteration and the involvement of many stakeholders.
Projects are managed through project management methodologies such as PRojects IN Controlled Environments (PRINCE2), and Gantt charts are often employed to map out how you will get from A to B and in what timeframe. At a program level, Gantt charts rapidly become overly complicated and you’re more likely to see a roadmap with aims and targets, but without the detail and structure of a project plan.
So why does this matter? It might be tempting to replicate how you plan and lead a project when thinking about a program. But it’s going to be impossible to scale and communicate effectively using the same approaches.
Having helped many lab-based organisations to run informatics projects and programs, we share some of our insights on how to lead, communicate, manage risk and account for human factors, when planning and rolling out both projects and programs.
Program leaders require strategic thinking, flexibility, excellent communication and stakeholder management, strong delegation, and empowerment skills, as well as effective team and resource management, among many other attributes.
While project managers also need many of these skills, their focus is much more task and delivery-focused. In short, they prioritise everything related to ‘getting the job done’, on time and within budget.
Program leaders have a much wider remit, from defining the strategic direction and focus, to creating a structure under which the ‘child’ projects will operate, managing ‘child’ project risks that could impact other ‘child’ projects, or the program as a whole. Program leaders are focused on achieving benefits, and strategic objectives that align with the organization’s vision.
Project communication is usually to a defined group of people on a regular basis, i.e. daily, weekly or monthly. Most people engaged in a project are involved to a similar degree and are very familiar with the details, so the level of information shared will be both quite granular and consistently consumed by all team members. Good communication within a project tends to be direct, detailed, and unfiltered.
For programs, where there may be hundreds of people involved with varying levels of engagement, cutting through the noise and providing updates that are impactful, relevant and easy to digest is key. Whereas ‘one size fits all’ may be suitable for a project, programs need to be communicated in various levels of detail, and, rather than relying solely on scheduled communication, benefit from participants ‘self-serving’ information.
Program leaders need to enable a shared awareness about what’s happening across the whole program, in an easily digestible format. A simple one-page graphic that shows the key milestones and summarises the roadmap can be effective and might be sufficient for some stakeholders. A program newsletter, outlining progress against key milestones and any major challenges or opportunities is another useful communication method. When sharing updates via tools such as Microsoft Teams, tagging stakeholders is a good way of ensuring your update attracts their attention.
Often Scimcon includes expert communications professionals within programs, who help determine the level of information sharing and recommend the best channels to use, as well as providing guidance on how to navigate organisational culture for the most effective program communication.
Risk management is critical for both projects and programs.
Typically, within projects, risks are identified, investigated, and mitigated as the project progresses. The risks are listed and managed within a regularly updated risk log.
Once again, the scale and complexity of programs dictates a different approach. Rather than identifying risks as they become apparent, a proactive and systematic methodology is required.
A technique we have borrowed from product development methodologies, such as the Lean Startup framework is Riskiest Assumption Testing, often referred to as RAT.
RAT is an effective technique that ensures the program’s most critical assumptions are identified and adequately tested, both at the start of the program, and on an ongoing basis. For example, at the start, one of your riskiest assumptions is whether your team can work well together at all. This needs to be tested early. See “Human Factors” below.
Other examples of riskiest assumptions:
RAT emphasizes rapid experimentation, learning from failures, and adapting mitigation strategies based on evidence.
If a project team works well together, it might be tempting to think that larger teams can do the same. The difference between leading small teams of 10-20 people and teams that are much larger is significant.
Program delivery success is influenced by a variety of human factors that can impact the effectiveness and efficiency of the program and could easily justify a dedicated blog post.
These factors include team dynamics, motivation and morale, decision-making, conflict resolution, issue escalation and knowledge sharing.
Let’s look at one of these – issue escalation – in a little more detail.
Early escalation of issues is a key success factor in the on-time delivery of projects. When confronted with an issue, well-meaning team members can mistakenly believe it is their job to solve the problem quietly and report when the resolution is complete. Often however, this results in the potential problem only coming to the wider team’s attention days or possibly weeks later.
The escalation process should be multi-tiered (‘heads up’, ‘warning’ and ‘escalation’) and transparent within teams, so that it becomes second nature for individuals to share any concerns with the right people, at the appropriate time. Regular problem-solving sessions or informal team meetings where the only agenda point is discussing/brainstorming any concerns, no matter how small, is a good practice and something we do ourselves and advocate with clients!
The connected nature of the program and the ‘child’ projects within the program means that the likelihood of human factors affecting delivery increases and requires ongoing monitoring and proactive management.
Projects and programs may appear very similar in nature however due to programs’ scale and complexity we highly recommend you don’t attempt to lead them in the same manner as projects.
We have hopefully provided some tips and insight for how to take the right approach when planning, leading and implementing projects and programs. To ensure successful outcomes, project / program leaders should include the key aspects of leadership, communication, risk management and human factors in their project or program planning.
If you need help with your upcoming projects or programs, contact us.
