The Paradigm of Project Management Tools

What is a Paradigm?

While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM,  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 the essential qualities of a subject in their 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 the system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to the project management tools, and how can this concept help software developers?

A Basic Paradigm: MS Project and Excel

I’m sure most of the readers have been facing the moment in their professional life, as they needed a tool for project management. Historically, most of us stem from MS Project and then Excel. MS Project 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 changes in agile software development? The project management paradigm shift  means that nothing is ever going as planned. The PM tools should undergo a shift as well, from routinely tracking the progress the way it’s been planned, to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and we’re still amazed at how many teams keep using Excel for agile project  management. Well, there’re 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 for it. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel. It isn’t a shared collab tool, someone has to keep this Excel file, and while Excel shows statistical trends quite OK, as for stock trading, but it takes habit, skills and extra time to tune it as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).

Excel used in stock trading

The Incomplete Paradigm: Beware Flaws in Assessment

There’re 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’ve worked with the leads and clients for quite some time, and what I’ve always been amazed at, that even until recently people have been using those cranky assessment sheets, that should be filled “yes/no” for random standalone aspects which would never put together the complete picture. Like, what changes if we put checks in all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”?  Such assessment sheets are clueless. They still give no clear picture of how the tool works, and whether it will address whatever needs and pains of this very company. The feature requirements as in those sheets  remind me of the flat geometry confined to the 2D surface. Somehow, they never have such bullets as “good data visualization”, “speed to change contexts and retrieve any data”.  That’s an apparent disconnect, where the task of selecting the project management tool is given to an administrative employee, and the real stakeholders, the people who will be working with the tool are left out of the initial screening stage. Well, might be that their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholder’s 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 around 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 is the same as the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on acquiring lots and lots of music gear.

I believe that if a company is building their agile dev 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 makes it out with the instrument in the show room (that’s 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 the assessment sheets and the 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 means 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 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 think.  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? The visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wonder why this human aspect tends to be overlooked by many.

Disclaimer: I didn’t mean to pitch any specific tools, or provide  reviews and recommendations, although it’s kind of more than obvious which agile PM tool is my favourite 🙂  My goal was to outline the paradigm to be used in the assessment of PM tools, and challenge some established patterns of thinking. When going off the beaten track, chances are high you’ll hit the bullseye of  your target board.. or process (couldn’t resist the pun 🙂