In the previous article we discussed how existing Work/Project Management solutions are lacking in the Viable capabilities needed to effectively manage Projects and that this leads to the use of a lot of separate systems and manual work arounds.  This in turn results in lost productivity, increased costs and increased Project Execution Risk.

Let’s look at each of these.

Lost Productivity

There is no doubt in anyone’s mind that having to use many different products to manage their Work or Projects is inefficient and results in a lot of inefficiency and lost Productivity.  Typically, it means wasting time switching between applications to different things that you need to get done, in order to do your job.  Just the time spent launching and logging in to different applications all the time is something we constantly hear complaints when we talk to people.  While this might not seem like much, it could be 15-30 minutes a day flipping back and forth.  If you think about it, that alone is effectively between 4-7% of a person’s total available productive time, on any given day, wasted just switching between applications alone. Now think of that in terms of a $1,000,000 project.  That cost you between $40-70,000 just for flipping between applications … Ouch!

Now the other thing that we constantly hear complaints about in this context is the fact the users are constantly having to copy data between applications or worse yet, once they duplicated the data in 2 or more applications, if they edit that data in one, they need to remember to update it in the others as well.  While this is clearly a huge risk (data ends up out of sync) the time spent doing this can be enormous, particularly in certain job functions.  For example, imagine a Product Manager or BA working in a company that uses both Jira and Confluence (both Atlassian products and a very common combination in Enterprise IT Projects ).  It is very common to write up a requirement in Confluence and then have to duplicate it in Jira.  While Cut & Paste is an option, it is rare that how it is written in one is the way it gets written in the other, so it takes time to duplicate either way.  Once you have it in both places, it is really common for that Requirement to get changed in some way in one of the two applications.  This requires the person to also make sure that it changes in the other location as well.  This need to duplicate data/effort can be enormous and is one of the most common complaints we hear when using both a Document form for Requirements and another system for Work/Task Management.  Managing Requirements represents, on average, 16% of the total cost of any Project and increases with Project Size & Complexity, with a good portion of that cost resulting from inefficiencies like this.

Another inefficiency that is common and related to copying and duplicating data, is when we need to process the same data differently in different software solutions, due to lack of capabilities in the original solution.  For example:  I often see people manually extracting data from Jira, Asana and other systems to then put it into Smartsheet, Excel or some other source just to do some data analysis or reporting on the data.  Again, this is very common, and on the other large Program that I mentioned in an earlier article, there were over 100 people in the Program office who were literally doing this every day all day as their sole reason for being on the Program.  It is extremely inefficient and costs companies a lot of money.

Increased Costs

While the inefficiency listed above obviously results in cost increase arising from increased time spent to get things done, there are other more direct costs which arise from having multiple system in play.

Firstly, there is the obvious cost of licensing resulting from having multiple pieces of software.  While each piece of software may be relatively inexpensive, on a per user basis, the fact that the firm needs to pay for 10-20 of them, results in significantly increased cost when compared to the potential savings that could be had if a few applications with better functionality could get the same job done.

In addition, there is always up front cost to install, configure, customize most of these applications as well as ongoing costs to maintain each of them.

Finally, we have the cost to integrate each of these system, in an attempt to reduce the inefficiency and manual labor spent replicating data that we discussed in the prior section.

It is not uncommon for a large firm to have dozens of people in the IT department, whose jobs are just to maintain these systems.

Increased Project Execution Risk

Last but definitely not least, is the fact that with many different systems, each having some of the data, or copies of the data and possibly not even having the same value when we copied the data, this fragmented environment is a direct contributor to Project Risk and resultant Project Failures.

Consider our example from the first section where we have a requirement in Confluence and again in Jira.  It is common the requirement to be changed at some point in time, either in Jira or Confluence.  The problem is that most of the time, that change never gets replicated to the other system, and even when it does, it is never exactly the same in both in my experience (one often has more detail than the other).  The result is that there is no single source of truth as to what the requirements were.

This is even worse when people are using Word docs along with a system like Jira.  I cannot tell you how many time I have found a Developer implementing a requirement that was based off a Requirement Document 3 or 4 versions back, and the developer has absolutely no idea that the requirement changed.

In addition, when different Work Items and Project Artifacts are spread across different systems, it makes it even more difficult to maintain Traceability.  Without Traceability it is impossible to manage change, which as we know is the single biggest cause of Project Failures.

Conclusion

The fact that the functionality in most existing Project Management systems is not actually Viable, on a feature by feature basis, causes users to require multiple different pieces of software to do their jobs.  This directly causes reduced efficiency, increased costs and dramatically increase Project Risk.

So let’s dig into some of the gaps.