It is common for companies to use as many as 10-20 different pieces of software to manage all of their Work Items, Projects and Programs.  I constantly hear complaints from Project Managers, Scrum Masters, Business Analysts and others about how much of a pain this makes it to do their jobs.  In addition, the CIO’s and CTO’s I talk to complain about the costs associated with maintaining all of these tools. It’s not just the direct cost of licensing, but also the cost of configuration, maintenance, integration and the more intangible costs such as the inefficiencies this introduces into the organization and the increased risks associated with not having a single source of truth.

Why Do We Need So Many Tools To Manage Projects?

The answer to this is simple. 

No single solution provides all of the functionality necessary to manage even smallish projects, in a single package.

Let’s look at a minimal set of functionality.  We usually need most of the following to do the job well:

• Document Management
• Requirements Management
• Task Tracking
• Test Management
• Issue Management
• Time Tracking
• Resource Management
• Estimation
• Collaboration
• Traceability Management
• Rule Based Automation

Now I can already see people jumping up and down waving their hands in the air because they are absolutely sure that Atlassian, Monday, ClickUp or some other system has all of this … but they don’t.

While I agree that yes, Atlassian sort of has a lot of stuff that you can check a box to say we have something here. If you combine that with third party addons for Jira you get more functionality looking like it is covered. The problem is that when you look closely, every one of the supposed features is lacking in certain ways to the point that the user wants to use something else that just does it correctly vs just doing something so the vendor can check a box.  The same is true for Monday, ClickUp, Asana, ServiceNow and the rest of them.

It is not enough to do something minimally.  You have to do it well enough to be useful and it has to provide the capabilities that the user actually needs.  Having a “Minimal” capability does not mean it is “Viable” for the user (I wrote a whole series of articles over at BeingCXO about this). 

Virtually all of the existing systems are packed with features that are only Minimal and are not Viable.

Lot’s of “Minimal” but “Not Viable” Features Results in Requiring Many Tools

Because the features are only Minimal, if they are there at all, and are not Viable, they just aren’t very usable by the users.  Assuming the user needs this feature to do their job, this means they need to find a Viable alternative for that specific piece of functionality, elsewhere.  This is often in yet another piece of software, which is how we end up with the problems we have now, where companies have 10-20 different pieces of software to get the job done.

In order to do this correctly, the capabilities within our Project Management solution need to be Viable on a feature-by-feature basis.

What does it mean to be Viable?

Well I would encourage you to go read the series over at BeingCXO, where I covered this in a lot more depth, but let’s summarize it here.

Being Viable

To be viable, you first have to understand the problem that your users have.  Let’s be clear, this needs to be an in-depth understanding of what the user needs, not just some high level “The user needs to manage Documents” or “The user needs to manage Tasks.”  You need to know exactly what the user needs to do with those Documents.  What does Document Management really mean to them.  I guarantee it isn’t just being able to attach Documents to items in a Board or to an Issue in Jira and maybe tell when someone uploaded a new version.  There is much more to it than that.

Once you have a complete understanding of what the user needs, functionality and capability wise, to solve their problem, then and only then can you set about trying to deliver a feature or solution that is potentially Viable for them.

To be Viable, the feature or solution must deliver enough functionality that directly addresses the User’s problem, to a level that the user finds significant value in that solution when compared to an alternative solution (which might be another product, or even to use nothing).

Conclusion

Existing Work/Project Management solutions are full of “Minimal” features that are “Not Viable.” This results in users seeking Viable alternatives for those features, elsewhere.  This may mean they do nothing or continue to do it manually, but it may also result in them using yet another piece of software for that capability in order to get the functionality they need to solve their problems and make their work life easier.

This results in companies having 10-20 different Work/Project Management related applications all addressing a small piece of the overall need.  This in turn massively increases costs, makes Work less efficient and dramatically increase the risks associated with Project execution.

We discuss some of the shortcomings of existing solutions in more detail in the next article.