Existing Work/Project Management Applications Don’t Cut It

So one of the questions I’m often asked is “Given that there are so many Work/Task/Project (pick your term of the day) Management solutions in the market, why did we choose to build another one at Proceve?”

Well the answer to that is pretty simple.

None of the existing Work/Task/Project Management tools provide the functionality I need to do my job!  None of the existing tools provide the necessary capabilities to directly and adequately address the main causes of Project Failure.

I have spent my career, including as a CIO, CTO and CRO, designing, implementing and running Projects and Programs for large scale compliance programs, process change and systems implementations, with budgets ranging from a few million dollars to $1.5 Billion, within the financial services sector.  I consistently find that I can’t effectively manage these initiatives with the tools available to me. Moreover, when I talk to other CIO’s, CTO’s, project and program managers, business analysts and others working on these and similar engagements, I hear the exact same issues, complaints and wish lists from them that I have personally.  Furthermore, there is a very high user dissatisfaction with the existing tools.  When we surveyed people from over 200 companies who use these tools for managing their projects, we had only 2 people in total who said they liked the tool they were using and that they thought it handled the job sufficiently!  That is a staggering level of missing the mark from a Product Market Fit perspective. 

Let’s take a look at what some of the key complaints and deficiencies are, using a recent project that I worked on for examples.

Project Background:

I was recently brough in to help salvage a large program for one of the S&P 500 companies, who were building a new complex software system with a Fortune 100 company as the anchor client.  This program was massive with 20 individual projects or work streams, each sub project had between 10-20 teams with 10-20 people per team and about 50% on top of that for QA functions and yet more for Program Management, Executives, Client personnel, etc.  Total head count was over 4000 people in total working in North America, Europe and India.

There were over 20 different applications being used to manage different types of Project Management Artifacts, Work Items, Reporting, etc.

To give you a sense of scale, in a single Project/Workstream, out of the 20 in the program, we had over 190,000 issues in Jira alone (and not all Projects within the Program used the same issue/task tracking system, which is a whole other issue).  

Can’t Organize Work Items and Project Artifacts

Unfortunately, most Work/Task/Project Management systems provide little in the way of mechanisms to Organize your work, beyond grouping them into Projects and/or assigning them to Teams.  Some allow you add Tags to items or provide some level of Grouping within a project(but these are typically in systems that really work better for small numbers of Work Items), but that is usually about it.

Needless to say, organizing 190,000 items in one workstream was virtually impossible, and we couldn’t even tell what needed to get done in order to finish any one specific Requirement like a single screen.

Can’t Manage Change

Changing Objectives and Requirements and the inability to manage that change, is the largest cause of project failure.  None of the systems currently on the market provide mechanisms to deal with this.

The most basic questions you need to be able to answer to handle this are as follows

• What Changed? (Many handle this by bombarding you with emails every time something changes)
• Given that Item A changed, what other Items are affected? (basically, none handle this, without a lot of manual effort going around asking people to think about it and get back to you with a list of what they think is impacted, which is utterly ridiculous)

Can’t Estimate Effort, Time, Cost and Resources Effectively

While most systems might allow you to put in an estimate in Story Points, T-Shirt Sizes, etc. this is almost useless from an estimation perspective.  How long will it take to implement 3 Story Points, or better yet 1024 SP in person hours, because at the end of the day it’s Person Hours that matter?  What will that 1024 SP cost in dollars?  How long will it take to implement that (SP is an effort measure, as is Person Hours, not a duration)?

If the estimate doesn’t allow me to:

• Estimate Effort, Duration and Cost
• Adjust Timelines as Estimates change and Items slip in the schedule

Then they are mostly useless make work that does not much more than allow me to determine how many items I can assign a team to complete in a set amount of time, which while important, is far from sufficient to actually manage something bigger than single team/sprint.

No One System Provides All Of The Necessary Functionality

On this Program we had God only knows how many pieces of software being used to manage different aspects of the Project Management and Collaboration functions.

Some requirements were in Confluence, some in Word, some in Invision and so on.  Collaboration was in Teams, Miro, and SharePoint.  Most Work/Tasks/Project Artifacts were in Jira, but some Siloes used different tracking systems.

The point is we had to constantly bounce from one app to another to do our jobs, which is very inefficient in its own right, but more importantly it meant that there was no single source of truth for anything and lots of stuff fell through the cracks as a result.

Too Much Manual Labour To Maintain Information In The Tools And Synchronize Data Between Tools

Given that the individual tools always lacked functionality that was required to manage the data in them, in an efficient and automated fashion, there was an absolutely massive amount of work that had to be done manually, that was a direct result of functionality lacking in the tools.

Furthermore, because data and functionality was spread across a large number of tools within the program, there were whole teams of people whose jobs were to do nothing but try and integrate those tools, including, in many cases, copying data manually from one tool to another, all day long. 

This is a huge waste or Person Hours, a massive cost, a direct source of data loss/corruption and a massive project risk.

Conclusion

Hopefully this high-level overview provides some initial insight into the deficiencies with existing tooling.

In the future articles, I will elaborate on each of these items, as well as others, in more detail, and will also provide some of our thinking about best practice for dealing with them.  First off though, we will look at what these inadequacies cost companies.

At Proceve, we are building yet another Work/Task/Project Management system, because the current ones, just aren’t up to the task. We set out to directly address these issues, and more. We designed our system from the ground up to meet the needs we see when managing very large-scale Projects/Programs, like the one mentioned here, but to do so in a way that also makes these capabilities easily accessible to small teams and startups, which I am sure will make for lots of iteration on the User Experience (UX) side to eventually get that balance just right.