As we have seen in previous articles, and I am sure anyone who has worked on any project, at any scale, has seen first hand, Objectives and Requirements change all the time!  These changes and the inability to manage them is the single biggest cause of Project Failure.

Minimum Requirements For Managing Change

To effectively manage change, you need to be able to answer three basic questions:

• What Changed?
• What is affected by that Change?
• What is the Impact of that Change?

Sounds simple, doesn’t it?  You would think so, but to be honest it is actually quite difficult to do.

Existing Software Usually Only Knows What Changed

It seems pretty clear that before you can manage change, you first need to know that something has changed.  Surprisingly, not all of the existing systems allow you to see what has changed in all of your various Work Items or Artifacts. ClickUp, Monday.com and Asana can all tell you when something has changed by looking at some variation of an activity view.  It’s not always easy to find changes related to a specific item, but in theory they can all do it.  The problem is it can also be hard with these to figure out what the state of the item was at a point in time before changes occurred, which you often need to do.  Jira does a bit better job, in that you can easily see changes to any specific item, from within that item itself (no need to go to a different view).  In addition, Jira allows you to see the before and after state resulting from the change, which is helpful.

One thing I hate (and everyone else I know echoes) with Jira is that every time something changes to any item I personally touched at some point in time, is that it assumes I want to watch that item for ever and it bombards me with emails every time anyone changes that item for the rest of time.  This clutters up your email inbox so badly that everyone always ends up creating filters to automatically clear the stuff out of their inbox.  This results in stuff actually being missed, but the alternative is you can’t find your other emails amongst all of the Jira notifications.  On that large project I mentioned in a previous article, it was normal for me to have to clear out 400-500 Jira notification emails per day, which is ridiculous.

You Don’t Know What Is Affected Without Traceability

It is impossible to know what is affected by any given change if you don’t know the relationships between the various Work Items and Artifacts in your Project.  The relationships between items are formally referred to as Traceability Relationships in Project Management.

Unfortunately most of the existing Project Management software don’t provide a mechanism to capture those Traceability Relationships.

Now before people start getting worked up about this and start flaming me, yes I know that in Jira you can define links and yes I am sure in Monday, ClickUp or Asana you can find a way to jury rig it by putting a textual reference to other Artifacts in comments, custom columns or fields, etc as a work around.  But, let’s face it, this is not sufficient to actually know what is affected by any given change.

Even in Jira, it is cumbersome to go into the interface and define all of the links, due to the way they are implemented and the poor UX around this feature.  Even if you do go in and methodically do this for every relationship (which is unbelievably time consuming and error prone), Jira:

• doesn’t have any reasonable way to effectively use the information
• only understands things at one degree of separation

The other systems, as I mentioned, have no real way to capture this information at all and even if you implement a jury rigged solution, the data is even less useable than it is in Jira.

Even in Jira, there is no way to define Traceability between say a Story or Task in Jira and a Requirement written in Confluence (the sister product from Atlassian).  At best you can embed a link (which is just a URL hyperlink in this case).  While this is better than nothing and in fairness, if you link a Jira ticket into a Confluence document, it does let you see the current status of that Jira ticket from within the Confluence document, but it won’t let you see any other content changes from that ticket.  Again, this is better than nothing but there is no way to find these Traceability relationships via a Query or other automated means.  You have to look at each item manually and visually identify that there is a link and then, again manually, determine if something changed and needs to be acted upon.

Moreover coming back to the issue of one degree of separation, imagine the following:

• I have a Requirement written in Jira as a Story
• I have sub-Requirements (which Jira has no concept of) also written as stories
• The best I can do is create a link between those sub-requirements and the parent and define them as a generic “Relates To” link type

Now imagine we also have Tasks which implement those Requirements and a Test which Tests each implementation and which usually has sub-Tests.  We link the Tasks back to their respective Requirements and also the Tests to their respective Requirements, again it has to be just a “Relates To” relationship (unless you customize your Jira installation), which is pretty vague.

So now imagine the parent Requirement changes.  What I need to know is what is affected by that change.  The answer should include every sub-requirement, every Task that is affected, every Test and every sub-Test that is affected.  The system needs to be able to see down that entire cascading chain of relationships in order to completely understand what is affected, not just relationships at one degree of separation. Now, in Jira, there is just no way to figure that out in an easy way, even if you go to all of the trouble to specify those various relationships.  It always boils down to a very manual task and someone spending a lot of time figuring it out.  This is extremely error prone and, more often than not, stuff falls through the cracks.

To make matters worse, because defining relationships between Items in Jira is painful in the first place, people just don’t do it in my experience and if they do it is very hit and miss.

So given all of this, while we can tell what changed in most of the products, it is virtually impossible to know what is affected by that change in the existing software.

Without being able to know what is affected by change we cannot manage change.  This leads to increased costs and continued Project Failures.

Determining The Impact Is Really Difficult

Let’s assume that we are able to identify everything that has changed.  Let’s also assume we know all of the Traceability relationships and the type of relationship beyond just “Relates To.”

Even armed with this information, I still need to know more in order to determine the impact of change. I need to know:

What Changed In The Item

In order to determine the impact of a change, I need to know what Item changed and what data, within that item was changed.  This is really critical.  The impact of the change is very much a function of what the change was.  If the change was a complete rewrite of the description of the Requirement, that is very different than simply changing the Target Start Date for a Task.

The Exact Nature of The Relationship Between the Changed Item and All Other Related Items

The types of artifacts and the nature of the relationship between the artifacts usually determines the nature of the impact a change to one artifact has on the other.

Example:

Imagine an Issue.  It hopefully is associated with the Test that found the Issue.  It should also be Associated with the Requirement that the Test was Testing, and it should also be associated with a Task that is assigned to correct the Issue, at a minimum.

Now if the Issue gets changed what is Impacted?

Well, the Requirement isn’t impacted at all, nor is the Test that found the Issue, but the Task to correct the Issue is probably affected.

The point is that the Type of Artifact on each side of the Traceability Relationship and the Type of that relationship allow us to determine whether something might be impacted or not.

Now let’s look at a different example:

Consider a Task (A) that has a sub-Task (B).  Let’s also assume that the sub-Task “Depends On” another Task (C) with a “Finish to Start” dependency type (more on Dependency Management here).  Now let’s assume that for some reason the Start Date for Task C is delayed and the Estimate is also increased.  This will automatically mean that the End Date for Task C is pushed out by more than just the change in its Start Date. Task B will have its start date delayed as well, as it can’t start until Task C finishes, which will also push out it’s End Date.  This in turn also might push at least the End Date for Task A (potentially, as there are lots more conditions that also need to be checked to make that determination).

So, in the first example, we are able to determine what is affected based in the types of Artifacts on each side of the Traceability Relationship and the Type of that relationship, but we couldn’t determine what the Impact of that change was.  In the second example, not only can we determine what is affected by the changes to Task C, but based on the Relationships, their Types and the specific data that was changed, we can actually determine exactly what the impact of that change is.

Conclusion

To effectively manage change we need to know:

• What Changed?
• What is affected by that Change?
• What is the Impact of that Change?

Unfortunately, most of the existing systems are not able to answer these questions, without a lot of manual work (if it can be done at all), which is why the inability to manage change is still the Number 1 cause of Project Failure, even after decades of supposed improvements in methodologies and tools.