The Paradigm of Project Management Tools
While there has been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM, etc., with the paradigm of agile prevailing at the moment, looks like no one has spoken about the paradigm of project management tools. What is a paradigm, in general? It’s a system of principles that unveils essential qualities of a subject in its entirety. From this perspective, a paradigm of PM tools would be a spot-on framework for choosing a PM tool. To make it more clear, a paradigm is something that allows a complete 360° view on any subject or matter. I’d say it’s not about the flat 360° view as in traditional geometry, but about a multi-spherical 360° view, as in the geometry of Lobachevsky. In linguistics, a paradigm is a complete set of all the forms of one and the same word realized through declension and conjugation, esp. as in German or in Russian. A paradigm represents a system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to project management tools, and how can this concept help software developers?
A Basic Paradigm: MS Project and Excel
Many readers must have had the experience of opting for or against a certain project management software. Historically, some of us have been “trained” to use MS Project and MS Excel. MS Project has served quite well as a clock ticker for the work that’s planned ahead and progresses exactly as planned. For waterfall, this narrow paradigm worked OK, assuming the project is flat and linear.
What has changed with the advent of agile software development? This paradigm shift implies that nothing is ever going as planned. The PM tools, then, should follow suit and undergo a shift as well, from routinely tracking the progress as per a set-in-advance plan to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and I’m amazed at how some teams still keep using Excel for agile project management. Well, there are some down-to-earth reasons behind this. Excel comes as a part of the MS software suite, and there’s no need to pay extra. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel: it is not a shared collaboration tool. Someone has to keep this .xls file up-to-date, and while Excel shows statistical trends quite OK, as for stock trading, it takes habit, skills, and extra time to make it function as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).
The Incomplete Paradigm: Beware Flaws in Assessment
There are many project management tools out there. Tons of them. It’s not easy to navigate in this space, and when someone is looking to select a PM tool for their company, they use some typical research methods… and bump against the same misconceptions. Let me give a brief outline of some approaches that I consider counterproductive.
First, it’s following a direct pitch. Remember, what happens when someone throws a link at you and says “this tool is just what you need”? By “someone”, I mean people who send haphazard intrusive pitch messages either directly to your email, or in social networks, etc. Normally you’ve got work that needs to be done right now, and you don’t want to interrupt your flow and switch to studying how this tool works, although it might promise a whole new world of miracles. Next, you have no idea if the person who throws the link is aware of your needs. It’s easy to throw a link at someone, but it’s not easy to decide for another person if that’s what they need. OK, you might be tempted to open the link to take a look, and invest some time in studying what it’s about. After taking a quick look, you decide that the pains from using your old tool do not outweigh the trouble and time that you need to invest in exploring this new tool, and you stay with what you have. That’s why following a direct pitch is the least likely way to find what you need (and from the marketing standpoint, the direct pitches are rarely successful).
Second, it’s PM tool assessment sheets. I worked with the leads and clients for quite some time, and I’m still amazed at how people use those cranky sheets, the ones that have to be filled with “yes/no” for random standalone aspects which would never put the complete picture together. How is this supposed to help if we put checks to all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”? Such assessment sheets are clueless. They still give no clear view of how a tool works, and whether it addresses whatever needs and pains of this very company. Feature requirements in such sheets remind me of the flat geometry confined to a 2D surface. Somehow, they never include the bullets such as “nice data visualization”, or “ease in changing contexts and retrieving data”. It’s a recipe for an apparent disconnect, when an administrative employee is assigned a job of selecting a project management tool, while the real stakeholders, the people who are going to work with it, are left out from the initial screening stage. Well, could be, their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholders’ precious time and add a few human requirements? Like, how human-friendly the tool is? Is it easy-to-use? Still, as much as I’m a wordsmith, I have to admit that no words in no assessment sheets will replace the actual feel and sight of a project management tool in action. The complete paradigm of PM tools is supposed to cover all the facets of multi-dimensional chaotic project management, including the human aspect. How about introducing the criteria of learning curve — simplicity/complexity — user background vs. ease-of-use? One can’t make an accurate assessment of those qualities from “yes/no” sheets.
The third most common misconception is related to all the buzz that surrounds agile, agile training, agile consultants, “we-should-do-agile-coz-everyone-is-doing-it”, etc. It’s about hearing of the agile adoption, and rushing to get an agile PM tool instead of taking care of the process first. This behavior reminds me of the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on buying lots and lots of music gear.
I believe that if a company is building their development process from within, they acquire their unique corporate expertise which is an asset in itself. It’s this unique expertise that finally helps them run projects with success and use the tools they need. Same with the GAS syndrome: you don’t know if you like this guitar until you play it. You can watch how a local pro does it their way with the instrument in the show room (similarly to what consultants do), or you can try and play yourself to get the actual feel.
The Human Paradigm: Comfortable, Visual, Multi-Contextual
So, we’ve covered the basic paradigm of Excel, passed over the hurdles of assessment sheets and functional requirements — what else then do we need from a PM tool? We need it to be human-friendly.
A human-friendly data/information capture and delivery by a PM tool implies two things: it’s visual, and it’s multi-contextual. I can’t think of anything that goes beyond this final layer. A parallel layer would be “learning curve vs. ease-of-use”, regardless of a user background. That would complete our paradigm: a sophisticated PM tool needs to be pleasant to work with and simple enough so people can learn how to use it just by themselves, with no outside help.
There’s more about comfort and ease-of-use than we’d normally assume. Positive emotions facilitate cognition and reduce cognitive burden. When people spend their time working with the PM tool that hinders their flow in one way or another, they get tired faster, and their higher cognitive powers “expire” faster. It’s not just a matter of pure design aesthetics or pleasant emotions. It’s about conditioning people to work more comfortably and successfully with software tools. We like nice architecture and pleasant interiors, so why should it be any different in the project workspace? A visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wish the human aspect had received more spotlight and clout.
Related:
5 Things We Need for Sustainable Performance at Work
Cognitive Endurance Basics for Software Developers
Back to the Future of Agile Software Development
This article has been re-written from an earlier story.
