Big Projects Need Full-Time Team Members

In smaller organisations, I rarely see the need for a project to last more than 4 to 6 weeks if the right decisions are made upfront. In larger organisations, however, bigger projects with larger teams often stretch across months, sometimes even a year or two. This is largely due to the increased complexity of managing change across a bigger team and organisation. Additionally, a larger budget tends to attract more scrutiny, which leads to more controls and, consequently, more overhead.

Based on my experiences with large corporate digital project rescues in the '90s and early 2000s, I developed a policy that my project teams should consist only of full-time members. This doesn't necessarily mean employees; full-time contractors are equally suitable.

This is so important because people in a typical project often come from different parts of the organisation and are managed by leaders with varying—and sometimes competing—priorities. This setup works if individuals are seconded for a continuous period, as they are effectively managed by the project manager during that time, rather than their original manager.

However, I frequently encounter situations where resources like business analysts, testers, and developers are spread thin across two or three projects—sometimes even more. This issue is especially common in teams still using cloud V1.0 technologies, which require a range of internal resources to architect, design, procure, and provision computing and networking equipment.

In these cases, project teams are often left waiting for critical personnel to finish tasks on other projects. Even scheduling meetings with these part-time team members becomes a chore each time, often resulting in longer lead times just to have conversations and make decisions.

These frequent, seemingly minor hold-ups (which are often not minor at all) are rarely tracked by project managers because the overhead of monitoring each delay is often greater than the value of managing it.

My commitment to full-time resources emerged after conducting a retrospective analysis of two large projects I ran, where I struggled to control the timeline and budget. It quickly became clear that, for a significant portion of the project’s duration, full-time team members were sitting idle, waiting on tasks dependent on part-time contributors.

This challenge is especially pronounced with roles that typically aren’t needed full-time, such as quality assurance personnel. In these cases, I address the issue by combining roles. For example, if I need 1.5 business analysts and 0.5 of a quality assurance person, I would hire two business analysts, with one of them assisting in quality assurance. While some people resist this type of hybrid role, my experience has generally been positive, as it provides an opportunity for cross-skilling.

I also developed several techniques for managing dependencies on part-time team members when dealing with cloud V1.0 infrastructure. However, I won’t cover those here, as these legacy technologies should no longer be used for new projects.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.