I had a fascinating email exchange this week. Not because it was positive—because it wasn’t—but because it was instructive. And I’m sharing the context and background with you (if not the identifying details) because I think there are insights to be gained for many of us. So in that life has served up some lemons, let’s make lemonade, shall we?
This starts with a webinar. I’ve been hosting a monthly webinar series for projectmanagement.com for yonks (which is about eight years, if you’re looking for a specific duration on that). Last week, I delivered my latest for them, asking “Where Will PM Software Go?” If that’s not an obvious enough title, the goal was to explore where we’ve been in the world of project management software, the problems that we typically encounter and how software would optimally evolve going forward.
Without relating all of the details of the presentation, a little background is useful. We’ve had project management software for pretty much the same length of time as we’ve had formal project management; about sixty years now. Early programs were mainframe based, and focussed on either schedule or cost. Today, programs are server or PC-based, but the functionality genuinely hasn’t evolved much. The scheduling software of today, for example, pretty much follows a direct and linear path all the way back to those early attempts at automation.
And that leads us to the gorilla in the room: Microsoft Project. Project unquestionably leads in terms of market share, and a ridiculous number of project managers—and innocent bystanders—have it installed on their desktops. Some even use it. Although, as with many of the software packages in the Microsoft Office suite—and arguably, many software packages in general—most users actually only take advantage of a fraction of the functionality of the software.
In terms of our current reality, that is a fundamental part of the problem. Much of existing software in the marketplace is incredibly complex. Trying to solve many of the problems of projects, project managers tend to get more and more granular in their approach, as they strive to get control over work, resources, workload, capacity, cost and schedule. The more we attempt to control, the less we often succeed. This gets us into a bit of a feedback loop, as subsequent failures result in even more detailed attempts to model a world that stubbornly refuses to be predicted.
These challenges are true, regardless of the software you use. Microsoft Project has its own particular issues (some of which stem back to version 1.0 when I started using it; for those keeping score at home, we’re at the functional equivalent of about version 16.0 right now). And without boring you with the details of those issues (although feel free to get in touch if you’re curious about them) they persist to this day.
In the presentation, I shared one example of an organization that implemented Microsoft Project and its associated server product. Expectations were set, projects were planned and schedules were built. Progress was attempted. And, as is more than a little predictable, people didn’t get their work done on time. So as progress was reported, activities moved in time. As well they should. If I was supposed to do 30 hours on a project this week, and I only did 8 hours of actual work, then it stands to reason that 22 hours of work is getting pushed out into the future.
The problem was that the project managers in this organization didn’t like this behaviour. In their view, they owned the project schedules. They controlled what happened. They determined what was and wasn’t late, and when work would and wouldn’t occur. And the solution was to strip out all dependencies from the project, fixing activities in time and indicating increasingly unrealistic schedules that completely failed to live up to reality. In the space of about two months, a $185,000 investment in software was essentially rendered unusable.
Now, was this a software problem? Yes and no. The software was working as it was designed, but not the way the project managers expected. The project managers should have expected it, mind you, but they didn’t like it. So instead they chose other approaches that behaved more in line with their wants and desires. The majority of the problem was around expectations, change management, training, understanding and knowledge. Underlying that was a complex software product behaving in—from the perspective of the users—unanticipated ways. And complexity got abandoned in favour of simple, but unrealistic.
Somewhere around here in the presentation is where the problems started, at least as I’ve been able to ascertain them since. Because what happened a couple of days later was that I got an irate and indignant email from someone who had seen the latter part of the webinar, and chose to entirely take exception to what I said, how I said it, and what it implied.
The person in question—who shall remain nameless—is a recognized expert in Microsoft Project. They’ve written books on the subject. They consult and advise on its use on a daily basis. And while asserting that they had no love for Microsoft—despite building a career on their products—they proceeded to take me to task for all the perceived misrepresentations I had offered.
They took particular exception to the prescriptive part of my presentation, where I discussed what we need to do to rethink project management going forward. This took a number of insights I’d discussed—what doesn’t exist, what isn’t easy, what isn’t understood, what is misunderstood and what is misapplied—and suggest what might be done differently. Everywhere where I indicated we needed to rethink approaches, they interpreted this as me saying “Microsoft Project can’t…”
That’s not what I said, nor is it what I implied. But it’s what they heard. Which, unfortunately, I have very little control over. And it’s objectively not true of any product. At this stage in my career, I can pretty much get what I want out of any product I use. It’s simply a question of how easy, straightforward and simple it is to do it. And usually it’s not, and that’s the problem. If software is cumbersome, difficult, needing extra software or extensive data manipulation to do what I want, I’m not going to be a happy camper. I’ll get what I need regardless, but it’s a question of “At what cost?”
I also mentioned—by name—a couple of software products that I viewed as exciting starts in being willing to rethink and reinvent project management software. This is, I believe, where my correspondent pretty much lost it. They certainly opined that because I had dissed Microsoft Project and praised other products, I had “shown my true colours.” Now, in the interest of full disclosure, I’m genuinely not a fan of Project. I use it because I have to, not because I want to. It’s complex, difficult, has some fundamental algorithms that have never worked, and is massive overkill for most projects that I manage.
If I’m entirely honest about things, however, I’m not a proponent of any other package. I’ve supported a good dozen or so implementations of project management software in as many organizations. In doing so, I’m famous for never recommending the same solution twice. Organizations need solutions that fit; they need to support their culture, their processes and their practices. And that’s what I will always advocate for.
The upshot of it all was that I was told that I had no business giving the presentation that I had, that I was clearly biased against Microsoft Project, and that in future I should make pains to consult with experts—and in particular my interlocutor—to verify my statements before I present them publicly. And also that it was hoped that I took the feedback as the constructive criticism it was meant to be.
In other words, and not so subtly, stay in my lane.
There are a couple of problems with this. First, I’ve been using the software in question for several decades, and I’m entirely comfortable with the assertions that I made. The problem is that the criticisms that I made of Microsoft Project were very few. They were pointed, but they weren’t the ones that they person was citing.
Secondly, what I think we need to rethink and reinvent I genuinely stand by. Yes, many of the things that I mention can be dealt with in some way. And it’s not easy, simple or straightforward. More importantly, because it’s not easy, simple and straightforward, many people engage in workarounds and subterfuge that undermine the intent of the software in the first place. And yes, that’s a usage problem rather than a software problem, but I don’t care. If the software as designed is encouraging people to opt out or undermine, it’s a problem. I don’t care whose problem it is, it’s a problem.
Thirdly, it’s a pretty offensive email to receive (and, by extension, to send). Sadly, the internet is where we say the things that we’re not prepared to say to each other face-to-face in polite company. And fortunately, I don’t get email or messages like this often. Which is perhaps why—when I do—I’m not prepared to simply brush it off.
So what do we do when not-so-subtly instructed to stay in our lane? What might we do, and how might we manage it? What is a reasonable response, and how do we engage in a way that makes our point, without further inflaming the situation? Here’s my survival guide:
For starters ask yourself whether it is, in fact, your lane. Now, for me that’s complicated. I don’t have a lane. I’m a generalist, and entirely proud of it. My “lane” encompasses project management, strategy, decision making, organizational politics and not a small amount of facilitation, behaviour, psychology and group dynamics. As a consequence, I’m thoroughly comfortable talking about project management, organizational approaches to project management and the software solutions that are available to support all of the above. I know the software, I use the software, and I’m completely conversant with the software.
Secondly, ask if you’re confident in the statements you’ve made, and how you’ve made them. This is where it gets annoying, in that you’ve actually got to go back and revisit (and preferably re-listen to) what you’ve said. Are there assertions that are untrue? Are there statements that are inaccurate? Did you misspeak, or generalize, or imply one thing while intending to suggest something completely different? I took the time to do this, and I stand by all of it. I get that some might not like what I’ve said (particularly if you’re Microsoft, or make a living supporting software produced by Microsoft) but that didn’t make what I said untrue.
Thirdly, and this is the hard bit, does the other person have a point? Are the statements they are making accurate? Might you have not been complete, or comprehensive, or clear? Have you omitted or glossed over important details they are calling you on? Might you have generalized in a way that doesn’t hold up under more detailed scrutiny? This is hard to deal with, in that it allows for the fact that—for all of our best intentions—we might have misspoke, or at least misrepresented. And there are absolutely times that I have done this. This wasn’t one of them, but it most assuredly has happened.
What I did recognize was that the accusations that were being directed at me were the product of misunderstanding. I actually replied to the individual, stating what I had been attempting to accomplish and what the underlying message I had intended was. I also pointed out that every time I stated a “we need” they chose to interpret that as “Microsoft Project can’t.” Their reply agreed with the—in their view—more nuanced interpretation. Which I’d actually been explicit about in the early part of my presentation. The reply also continued to suggest that my bias was showing, which says a lot more about them than it does about me.
Separately, and distinctly, what should you do if you’re tempted to tell someone to stay in their lane? In this, I would argue for caution. There is a lot of “should” in that assertion, and in my experience there is very little mileage to be gained in telling someone what I think they should do. In fact, it’s the advice that I’m inclined to discount and dismiss first.
If, however, you feel compelled to go there: ask yourself, first and foremost, what you are annoyed about. Are the statements actually untrue, or is it that you just don’t like them? Does the person genuinely lack the expertise or qualifications to be making the statements that they are? Will harm come from people taking the statements at face value, without greater understanding or insight? Is someone telling blatant falsehoods?
If any of these questions can be answered in the affirmative, then think about it. But also think about how to present your observations, your feedback and your recommendations in a constructive fashion. If you’re truly annoyed, walk away until you can actually be constructive. And make sure that what you are saying is true, that you are not misunderstanding or misinterpreting, and that the facts back you up.
We live in a time where we have a complex relationship with the facts. Falsehoods routinely go unchallenged. Assertions get avoided because it’s too much work to argue. But change is only possible when we can offer—and explore—a different perspective. That’s where “stay in your lane” becomes a pernicious statement. What it is—not too unsubtly—saying is that we should shut up.
Progress is only made, however, when we are willing to explore alternative perspectives and challenge uncomfortable truths. “Stay in your lane” is very often a reaction that asserts discomfort with what is being said, rather than outright disagreement. It’s a minimally implicit—and often explicit—assertion that the powers-that-be won’t like what you are saying, and so you should speak differently. And that says much more about the person admonishing us than it does about us. The more beholden we are to the status quo, the more inclined we are to navigate between the lines.
If we care about change—and we recognize that is needed—then we need to be willing to cross the line, and also to explicitly acknowledge that we are doing so.