“We’d like to move to more transactional project management,” was the most often repeated phrase I heard this year in project management circles.
For some, this is a cry from Millennials (those born between 1981 and 1996) to reject the ancient project planning relics of the past and move into more modern thinking. “Let’s go Agile,” is the first call. “Let’s use one of the new project tools like JIRA or Trello,” are also signs of these desires.
If you buy that this is a Millennial movement, then you probably also are of the opinion that Millennials are intent on instant feedback, have attention deficit and require reasonably constant entertainment and stimulus.
Several major project management tool publishers have announced that they will embrace this movement to more “transactional” project management and herald it as a leap forward from the luddite views of old project managers towards more modern and more gratifying project management practices.
I’m not so sure.
There’s a lot to unpack in those four paragraphs so let’s take a look at a couple of things.
What industry are we talking about?
First of all, most of the chatter about this subject is mostly coming from software development industry where there is already a significant movement to adopt Agile as the main stream of doing project management. The tasks in an Agile environment are imagined to be in a big bucket of tasks that we take as we move forward in sprint after sprint. My own development department at HMS has worked this way for years.
Most programmers I have encountered consider themselves to be more artist than engineer so the idea that they would work in a managed is abhorrent. (Yes, even in my office.)
But…
There are some aspects to the project management world that don’t fit into Agile. “What about a budget?” I ask. Agile people shudder, “We don’t need to talk about that,” they say.
“What about market demands for delivery?” I ask. “We’ll give you what we can give you,” the Agile people reply.
I have been on numerous panels in project management conferences in the last ten years where I’ve been expected to defend the Enterprise Project Management practice. “He’s the waterfall guy,” someone will say, pointing at me.
But when I ask the Agile people if they have a “pure” Agile environment, even the most ardent supporters agree that they do not. In a large organization, the nuts and bolts of project management often falls to a part of the organization that is more strategic than tactical. They will create a more classic project structure and within each phase or even summary task, they will expect many activities to be created in the backlog for Agile people to work on at the tactical level. This is more of a hybrid environment but the business necessities of budget, authorization to do the project, stage gating, market delivery and more falls at a more senior decision making level.
Almost all of this kind of structure occurs in the software industry but as I’ve pointed out in these very pages, many other industries can function with Agile Methodology as well.
So with a more Agile Methodology being more popular, at a tactical level, we are seeing a movement towards more transactional project management. But this isn’t enough to explain a whole movement.
What is the payoff for transactional project management?
When I am pitched a new method by someone, I’ll often think of what benefit they might receive by working that way. When I think of transactional project management, one thing comes up over and over and over.
If you don’t have a plan, you’ll never be late.
When you are only responsible for one task at a time, one thing that becomes obvious is that you don’t expect to take on any accountability for the whole picture. In fact, you don’t even plan to take on any responsibility for the impact of the one thing you’re working on. In my own office, we work along Agile lines in development all the time. And on a semi-regular basis, we’ll have a developer show us a function they’ve improved or written or altered because that was their whole focus but which we’ve had to back peddle on because it affected many other areas of the product. It’s one of the downsides of being less managed and more independent and, to be fair, we often are able to weave new innovation that arrives at us sideways like that into the product at a later juncture. But even in our organization, the underlying project management standards are being applied from an over-reaching perspective by management.
If the staff were given free rein to manage their workload just from possible tasks in a backlog, even with some guidance from a scrum master, one big payoff they’d see is not having to worry about the over-reaching perspective by management. That’s quite attractive for an individual worker no matter what industry they’re in. Not so much for the organization that pays him or her.
So is it those darned Millennials?
I don’t think it is. I’ve got Millennials all around me but I think laying this movement at their feet is somewhat unfair. What is more likely is that this desire is getting a lot of software tool industry attention because it sounds like the “next great thing” and even workers in that industry see the attraction to not having to be accountable for an old-fashioned plan anymore. I spoke to a colleague recently who had been at a project management conference and was being pitched hard on how he should adjust his own project management thinking to be more transactional.
“How are you supposed to do a project estimate if you do that?” I asked. “I think I’m supposed to guess…” the colleague replied, sounding confused.
So do we move to transactional or not?
The answers to all of these questions is always “It depends” but in this case, you may find that parts of your organization are already there. Agile tools are plentiful on the market. If you’re in software development you already know this. If you are in other industries, the applicability of Agile-type processes depends on what you do and how you need to do it. It’s all very well to say “We will work on that task in the next sprint” but if that task is government regulatory approval, it’s probably not so transactional.
You may be feeling pressure to choose one of the many incident or task tools that are on the market and wondering if these tools should replace more traditional tools. The answer may be different for every organization but my guess is that mostly these new task tools are good to use at a tactical team or individual level but not so much for more management or strategic level processes. So a blend of tools is more likely to be your answer.
As is the case with all changes in your environment, don’t forget to ask yourself what problem this change is supposed to be a solution for.
