These three elements are important parts of R&D programs, regardless of whether a project phase is skewed more towards the “R” or the “D” side of the spectrum. Each topic can be treated independently with an entire book’s-worth of depth, and each will be the subject of future blog posts, but a cursory discussion here is prudent to examine how they interlink.
The base of literature that I’ve read in the R&D management field has a varied approach to these topics, but I’ve noted that rarely do they combine them to look at the interplay at a project outset. Planning a project is most often treated from a very structured date-and-milestone-setting perspective. Scheduled meetings, itemized rankings of on-target versus slipping, red-flags, yellow flags, mid-point reviews of the plan are all the norm. That approach also feeds into the not-always-successful “project-manager-as-an-isolated-role” philosophy that has become common in the R&D management psyche in recent years. Under generally applied PM theory, an individual, often with only cursory understanding of the subject under consideration, will track a list of deliverables against schedules and perform the associated data-capture and pestering behaviours to push a project forward and chart the progress. The result is a decoupling of conceiving and planning from tracking and oversight.
In theory the project manager will filter the information from the front lines into charts for the program director. The motivation is that the director can direct a wider number of projects with a clear view of project status, gathered with low effort, from whence decisions can be made without all the messiness of interacting with the individual contributors to the project on a daily basis.
Where this falls apart is that often the project manager is neither a subject expert, nor holder of directing authority. The somewhat confrontational element to the PM role erects a barrier between team members and the PM office, and creates a less than positive dynamic. From the individual contributors perspective, the project manager has regular interactions asking
- where you are on these deliverables?
- are you still on track for your milestones?
- why aren’t you on track on some deliverables?
- I want you to work harder to meet this date
All these have the hallmarks of authority, judgement and control over the individual’s work, yet complexity in the “why” answers may often be lost on the project manager, due to lack of depth in the subject at hand. This becomes apparent to both players quickly, causing defensiveness in the PM and frustration for the researcher/developer.
The interaction creates work-stress and loathing of the impending interaction where these questions will arise. These stressors possibly coupled with the interrogator having only cursory subject knowledge and a low-rank on the totem-pole of the meritocracy can result in conflict for an R&D team.
The on-going tracking of progress is important in managing an R&D program, but it is equally important that the management process be sensitive and dynamic in dealing with the uncertainties of the project. Indeed, the uncertain nature of R&D work should have contingency elements in the original plan. It’s a delicate balance for an R&D director to trade-off productivity-expectations in solving challenges and retain tolerance for dealing with uncertainty.
A counter-intuitive notion is that uncertainty, and road-blocks to progress, should be seen as positive elements in projects that ultimately hope to deliver commercial advantage. Each difficulty is a particular barrier to competition, a point at which a less-worthy adversary may be left behind, assuming your team is able to persevere and progress to a solution.
Thus we recognize that motivation during a project requires pre-planning that accommodates a suitable level of uncertainty. But also required is an ability in the manager to guide, discuss, and appreciate the challenges that arise. To make judgment calls about a difficulty that requires support and coaching, versus one that requires simply more committed effort from the researcher/developer.
As part of that, a manager needs to have a body of experience which enables the coaching and support that aids an individual through the challenge at hand. These are typically drawn from experience with subject-specific knowledge, but more generally a seasoned manager brings transferable techniques that can be independent of the current subject. A breadth of experience, and balance in applying directing and supporting behaviours are sometimes discussed in management theory. (This also forms the basis of techniques of “situational leadership.”)
Now this part is important – The strength and cohesion of a team is built on how these barrier-situations are handled. When they are managed through a collaborative process, by leaders with the right balance of authority and responsibility, successes that are achieved build a foundation for the organization on which strong future projects are built.
When directing behaviours without coaching/supporting behaviours are applied with a contributor who is facing unfamiliar territory, or worse, when schedule-centric behaviours decoupled from subject-matter knowledge or coaching ability are applied, foundations are eroded.
A strong planning tool is to ensure there are enough mid-project milestones to detect a project getting off-the-rails early, rather than having a surprise days before a long-term project is supposed to deliver results. From a motivation and reward, perspective, the director should similarly schedule check-points to test for enthusiasm and motivation so that encouragement and support (both moral and material) can de-risk a project in danger of fade-out.
In a future blog entry I’ll discuss the motivation factors around individual self-actualization, challenge and reward. There’s a big body of work on this topic (e.g. Redmond and Stephens in the refs) and I have some observations from a couple of decades in the trenches. These concepts are important in solidifying the experience of a well-led project into building blocks for future projects, rather than creating a sources of recurring weakness, like dry-rot in the frame of a house.