If Existing Work/Project Management Tools Don’t Cut It, Why Hasn’t Someone Already Built a Better One?

In a previous article I talked about one of the main questions that we get asked at Proceve, which is, “Why are we building yet another Work/Project Management tool?”  The answer to which, is that the existing tools just don’t cut it.  The other main question that we get asked all the time is “If the existing tools are inadequate, then why has nobody already built a better one?” 

The answer to this boils down to the following:

• Very few people have an in depth understanding of the Problem that needs to be solved, and can identify the root cause(s), in order to eliminate Project Failure.Without this you cannot develop the Requirements that need to be met (at a detailed level, because I can tell you, the devil is in the details) in order to design a “Better” alternative
• A better Tool is extremely complex from a functionality and software design perspective
• Very few people/teams in the world, have the combination of experience in managing large complex programs, needed to understand the Requirements, and the Software Design skills necessary to pull this off, even if they wanted to (thus why existing tools miss the mark)
• Building a “Better” and “Viable” alternative to existing tools is not only extremely difficult, due to the reasons above, but it is also extremely expensive (We estimate a $75-100 Million cost to reach an MVP using traditional development approaches … which we don’t use)

Let’s look at each of these items in more detail.

Understanding the Problem You Are Solving

Designing software to solve the causes of Enterprise Project Failure is very different that setting out to make a better Todo List or Task Management Application.  The latter is fairly simple and there are hundreds of them available in the market with very little to differentiate them, while the former is very complex.

NOTE: For a brief discussion of some of the main players in this space, their history, strengths and weaknesses, see this Article.

None of the existing players started out trying to address the needs of Enterprise Project Management.  They all started as tools to manage Todo Items, Tasks or in Jira’s case Issues (Bugs) and mostly for small team environments, because that was the specific need and problem they themselves understood and had.

In order to design and build a system that truly addresses the needs for Enterprise Project Management, you need to know that space cold.  You have to have lived in the space for decades and seen enough projects, companies and system to understand the good, the bad and the ugly of them all.  You have to not only understand the problems and what can be done better, but also what is the root cause of that problem.  You need to be able to answer the question “What do we need the software to do in order to properly handle the constantly changing Objectives and Requirements as efficiently as Possible?”  It’s not enough to know that change is bad, you have to know how to fix it.

Furthermore, it’s not enough to just understand one problem in the space, you need to understand the complete set of requirements, in detail, for the entire problem space and how to solve all of the problems and functionality gaps.

Designing The Software to Directly Address The Problem

So you think you understand all of the requirements well enough to define the complete set of functionality needed for a new system in this space.  That’s great, but do you know them at a level of detail that’s sufficient to meet the needs of the most demanding Enterprise at scale.

For example, you might think you need the following requirement:

• The system must have a timeline view that shows items against a calendar like in a Gantt Chart

That’s great, but is that enough or does it need more?  Like this detail:

• The system must allow the user to specify dependencies between Project Artifacts
• The System must understand all 4 types of Dependencies
• The System should automatically updates items on the timeline based on changes to items in the dependency list

This is now getting a lot better (and BTW, many of the existing systems are not able to do the last 2 bullets in their timeline view), But for a large enterprise, this is still not enough.  You probably need more requirements, like these:

• The system shall not restrict dependencies to just Tasks, or even between Artifacts of the same type
• The System shall not assume that all items that need to be updated are currently loaded in memory in the application
• The System shall support millions of artifacts, all of which may be dependent on each other
• The System shall allow for dependencies across Projects
• The System shall process cascading dependency chains in an asynchronous manner while still maintaining transactional integrity (so no data is lost and no dependency fails to be updated when a change is made)
• The System shall send update notifications to the user interface as dependencies are updated
• The User interface will immediately respond to update events and load updated data into the UI and immediately reflect those updates

As you can see there is a huge difference between just knowing that you need a timeline view suitable for a small team and one that meets the needs of say Boeing who is trying to assemble a plane (and this isn’t even 5% of the requirements to do a timeline correctly).

So defining the requirements in a manner that correctly specifies the functionality needed to support an enterprise use case is no joke and requires an understanding of both the business and technical requirements at a level of detail that very few people understand.

Now assuming you could get all of the requirements correctly defined, designing the system to meet those requirements is even more difficult.  Doing this correctly to handle even a single large enterprise, never mind many in a SaaS platform, is extremely complex. I can count the number of people I have met over the years, on the fingers of one hand, with many fingers to spare, who might be able to tackle it. Which leads to my next point.

Assembling The Right Team

So first, you need to assemble people who understand Program/Project management well enough to define your requirements in detail.  Secondly, you need to assemble an extremely strong technical team, that understands how to design and build a very large and complex system. Most developers will never work on a piece of software as large as an Enterprise Project Management Solution needs to be. It needs to handle massive data, huge transactional volume, be highly secure, reliable and stable.

This is no small task, and putting together a team like this is not easy.  At Proceve our initial team had an average of 23 years of experience each designing and building enormous systems (including many of the World’s leading Stock Exchanges, Banking Systems and major internet sites).  We had 150 years of collective experience dealing with the issues on the Project/Program management side and over 200 years of collective experience on the technical side.

Funding The Development

Finally, and this is the real kicker that stops someone from doing this, assuming you assembled your team, defined all of your requirements, designed the perfect system, who is going to fund it?

Our best estimate to develop the system we are building at Proceve is that if you were to do this using traditional development (which we aren’t), then it would require a team of between 100-150 developers somewhere in the 3-5 year time period to get an MVP out the door.

At Proceve we have the advantage that we happen to have spent 22 years developing advanced automated software development technology (which we are currently preparing to file 12 patents on) that dramatically accelerates our development.  This technology currently allows us to obtain 91% of our total code base fully automated and we are hoping to improve upon that going forward.  Without this technology, we could never have considered developing this massive piece of software.

Even then, Proceve is fully founder funded to date.  There is no way that a VC would have been willing to fund this prior to an MVP and seeing some traction.  The problem is that when the MVP costs up to $100 million to build, this isn’t going to happen.  Most Founders are not going to be able to fund a big build like this and they don’t have our technology to bring the price down. (For a discussion on Why Products are often Minimal and Not Viable check out this blog post.)

Even if one of the big players in the space wanted to start from scratch (and they would need to do exactly that because none of their current technical architectures can be easily changed to deliver a complete solution) it would be a massive undertaking (probably 2-3x the $100 million due to technical debt and corporate politics). There is just no way their management or investors would allow them to basically throw out their current solutions and start again.

Conclusion

As this hopefully demonstrates, the reason that no one has already built a better solution, even though the current ones are deficient, is because:

• It’s a really complex problem
• The build is extremely complex to design and build
• It’s extremely expensive to build

So Proceve is taking on the challenge and even then our Roadmap is years long after the first release.