In order to work as intended, this site stores cookies on your device. Accepting improves our site and provides you with personalized service.
Click here to learn more
Click here to learn more
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.
Industry leader interviews: Jana Fischer?Our team at Scimcon is made up of a talented group of interesting individuals – and our newest recruit Ben Poynter certainly does not disappoint!
Ben joined our Scimcon team in July 2022 as an associate consultant, and has been working with the lab informatics specialists to get up to speed on all things Scimcon. We spoke to Ben about his experience so far, his interests, background, and what he hopes to achieve during his career as an informatics consultant.
So, I studied Biomedical Science at Sheffield Hallam University, which was a four-year course and allowed me to specialise in neuroscience. During my time at university, I created abstracts that were presented in neuroscience conferences in America, which was a great opportunity for me to present what I was working on. My final year dissertation was on bioinformatics in neuroscience, as I was always interested in the informatics side of biomedical science as well.
Once COVID hit, I moved into code work, and worked in specimen processing, and then as a supervisor for PerkinElmer who were undertaking some of the virus research. When things started to die down, I began working for a group called Test and Travel (not the infamous Track and Trace initiative, but a similar idea!). I started there as a lab manager, training new staff on lab protocols for COVID-19, and then a month into that I started working more on the LIMS side – which is where I ended up staying. I wrote the UAT scripts for 3 different companies, I performed validation on the systems, I would process change controls. I then moved to Acacium as LIMS lead there, so over the course of my career I’ve worked with a number of LIMS and bioinformatics systems, including LabWare 7, LIMS X, Labcentre, WinPath Enterprise, and Nautilus (ThermoFisher Scientific).
In the early stages, I would have to say it was when Jon and Dave led my first interview, and Jon asked me a question I hadn’t been asked in an interview setting before. He asked me ‘who is Ben Poynter?’. The first time I answered, I discussed my degree, my professional experience with LIMS and other informatics systems, and how that would apply within Scimcon’s specialism in lab informatics consultancy. Then he asked me again and I realised he was really asking what my hobbies were, and how I enjoyed spending my free time. Since starting at Scimcon, I’ve been introduced to the full team and everyone is happy to sit and talk about your life both inside and outside of work, which makes for a really pleasant environment to work in. Also, it seems as though everyone has been here for decades – some of the team have even been here since Scimcon’s inception back in 2000, which shows that people enjoy their time enough to stay here.
I’ve been given a really warm welcome by everyone on the team, and it’s really nice to see that everyone not only enjoys their time here, but actively engages with every project that’s brought in. It’s all hands on deck!
So, my main hobbies and interests outside of work are game design, as well as gaming in general. I run a YouTube account with friends, and we enjoy gaming together after work and then recording the gameplay and uploading to YouTube. We are also working on a tower defence game at the moment, with the aim to move into more open world games using some of the new engines that are available for game development.
In addition to gaming and development, I also enjoy 3D printing. I have a 3D printer which allows me to design my own pieces and print them. It’s a bit noisy, so I can’t always have it running depending on what meetings I have booked in!
Technology is a real interest of mine, and I’m really fortunate to have a role where my personal interests cross-over into my career. The language I use for game design is similar to what I work with at Scimcon, and the language skills I’ve developed give me a fresh perspective on some of the coding we use.
At the moment, I’m working on configuration for some of the LIMS systems I’ll be working with at customer sites, which I really enjoy as it gives me the chance to work with the code and see what I can bring to the table with it. Other projects include forms for Sample Manager (ThermoFisher Scientific), making it look more interesting, moving between systems, and improving overall user experience. It’s really interesting being able to get to grips with the systems and make suggestions as to where improvements can be made.
My first week mainly consisted of shadowing other Scimcon lab informatics consultants to get me up to speed on things. I have been working with the team on the UK-EACL project, which has been going really well, and it’s been great to get that 1-2-1 experience with different members of the team, and I feel like we have a real rapport with each other. I’ve been motoring through my training plan quite quickly, so I’m really looking forward to seeing the different roles and projects I’ll be working on.
I’d really like to get to grips with the project management side of things, and also love to get to grips with the configuration side as well. It’s important to me that I can be an all-round consultant, who’s capable at both managing projects and configuration. No two projects are the same at Scimcon, so having the capability to support clients with all their needs, to be placed with a client and save them time and money, is something I’m keen to work towards.
For more information about Scimcon and how our dedicated teams can support on your lab informatics or other IS projects, contact us today.
Outsourcing a remote LIMS validation?2020 has been a difficult year for most industries, not least for event and tradeshow providers. Luke Gibson, Founding Director of Open Pharma Research and Lab of the Future, shares his experience of running events in the laboratory industry, and what makes Lab of the Future such a unique event.
My name is Luke Gibson, and I am one of the three founding directors of Open Pharma Research. I have 30 plus years of experience in developing and running events, primarily in the financial and trade and commodity sectors. My colleagues Kirianne Marshall and Zahid Tharia bring a similar level of experience to the company.
Kirianne has had many years of experience in managing the commercial side of large congresses, such as Partnering in Clinical Trials, and research and development congresses. Zahid has 30 years of events experience too, particularly in running life science portfolios, and launching congresses/events. Our paths have crossed many times throughout our years working in events, and we eventually hit a point where all 3 of us had the capacity to try something new – something that was worthwhile, fun, and different to the corporate worlds we had become accustomed to. So that was why we created Lab of the Future – with a view to running events in a different way.
I’m not sure if I would describe it as a gap in the market, more an ambition to do things differently. There was a desire from all of us to build an event with a different approach to the one we would take when working for large organisations, because when you’re working on a large portfolio of global events that cover a variety of topics, you and your team are always looking ahead to the next event, and the focus on the longevity of a single event isn’t always there.
We wanted something that we can nurture and grow, something that we can work on year-round without getting distracted by the next thing on our list. It also allows us to stay within this space and build our community, without having to face pressures such as a year-on-year development strategy or diverse P&L. Our desire was to avoid these constraints, and create an event that we can continue to work on for a long time.
We want to be able to live and breathe Lab of the Future, but one of the interesting things about it is that it’s such a broad concept. On the one hand we deal with informatics, but on the other hand, we deal with equipment, technology, and all the connectivity between them – but even that’s just one part of it. We are not an informatics conference; we are not strictly an instrumentation conference; we also look at the innovation side of things.
I think the best way to describe how we see Lab of the Future is as a proxy for how you do science in the future. Everything pertains to more efficient processes; better results; or ways of creating breakthrough innovation, and these are all part of the picture of science in the future. And that is the lab of the future – where the lab is the proxy for the environment where you do the science that matters.
When we started off, we found we received a lot of queries from industry contacts who wanted to get involved, but certain topics they wanted to discuss didn’t necessarily pertain to the physical laboratory itself. But if it was relevant to science, then it was relevant to us. Things like data clouds and outsourced services may not be directly linked to the lab, but they still relate to how you work. So, within that, the scope for the Lab of the Future gets wider still, looking at areas such as how we can create virtual clinical trials, or use real world-data to feed back into R&D.
People are also keen to learn more from their peers and from other areas of the industry. Lab of the Future allows us to host senior speakers and keynotes who can tell us where we’re heading, and show us how the efforts of one area within life science feed into other areas. It presents us with an almost ever-changing jigsaw image, and it’s this strategic element that I think sets us apart from other events.
We attract a real mix of attendees, and that’s what I love about it. You can run a conference for people in a specific job function, such as a data scientist or an R&D manager, but what people really want to know is what the people around them are doing, to almost give them context of the industry as a whole. So, our conference doesn’t just exist to help you do your own job better, but it helps you to develop a concept of where your department is heading in the future, and what you should think about longer term. We aren’t telling scientists how to do their job today; we’re helping them think about their responsibilities for delivery in the future. Lab of the Future is about the delivery of science of the future.
Our sponsors and solution providers that support the conference are also very much part of our community, as they’re all innovating and making waves in this space as well. They’re in a space that’s always evolving to build the Lab of the Future; and they are part of that solution. So, we don’t merely facilitate a conference of buying and selling between providers and services, we offer a space where everyone is evolving together. It’s a real melting pot, and that’s the fun bit really.
Zahid’s background in life sciences definitely gave us a starting point. Further to that, we’ve found that every time we put something out, that our community engages, and as a consequence we’re introduced to people we never expected to be introduced to. The fact we’re always talking to people enriches our content – the people we meet and conversations we have change our way of thinking, and shape what we’re doing.
Although I’m in charge of our marketing operations, I have to say I’m not always sure where some of our contacts come from! One thing I’ve found quite surprising is the lack of reliance on a database – there’s a lot of power in word-of-mouth, especially in this space where everyone is working on something – why not share that? As we’re seen as adding value to the conversation, it allows people to find us through their connections and our supporters.
Scimcon is proud to sponsor Lab of the Future, and we can’t wait to see you at the Autumn virtual congress on 26 – 27th October 2021. Contact us today to learn more about our participation in the event, and stay tuned on our Opinion page for part 2 of our conversation with Luke.
The role of AI and ML in the future of lab informatics?