OK, raise your hand if in your projects you regularly find yourself trying to create complex naming schemas, tagging mechanisms or other ways to organize all of the work items or project artifacts you need to manage.

Those of you who didn’t raise your hand are probably only dealing with really small projects with small teams or are too embarrassed to admit you tried this too. For those of you who did raise your hand, how many of you found that this mechanism worked?

I see none of you have your hand up anymore.

If you look back on the previous articles, where we talked about the causes of project failure, you won’t see lack of organization as one of the causes listed in any of the research. Despite that, in my personal experience, this is actually one of the root causes of many of the items that do make the list. In addition, across the hundreds of interviews that we performed at Proceve with people overseeing and working on projects at dozens of the Fortune 100, Government and hundreds of startups, everybody agreed that this was a major issue and that none of the existing solutions work.

To give a really basic example that I personally experience all the time and most other people I talked to confirm they have the same issue:

When I’m building a piece of software, in order to support the functionality on any particular user interface screen, it might be necessary to have various APIs developed, databases, business logic implemented and much more over and above the development of the user interface itself. Typically, this is going to result in many requirements being written for each of the various components supporting that one screen and one or more tasks being written and assigned for each of those requirements. In addition, there’s testing for each requirement which may include many individual tests and from those tests we may report many issues that then need to be addressed with yet more tasks.

So with all of this in mind, a common question that we might need to ask is “What’s still outstanding to complete this screen and how long will it take before it’s done?”  While it seems pretty obvious that you should be able to easily answer this using your project management software, I am not aware of any software currently available in the market where you can immediately get the answer to this question directly from the software.

While there are a number of reasons why existing software can’t give you this answer, and we’ll discuss that in depth in subsequent articles, one of the main reasons is that none of the existing software even knows that those Requirements, Tasks, Tests, and Issues relate to that screen. They lack mechanisms to organize all of this in a way that makes those relationships immediately identifiable. Most of the systems don’t even have the concept of Requirements, Tasks, Tests, Issues, Documents, etc as being distinct artifact types with unique features and behaviours, never mind maintaining traceability between them (but we will talk about that more when we discuss change management in another article)!

Items Need To Be Organized In Ways That Relate To Units Of The Product or Business Process

Ideally I find that you typically want to be able to organize Work Items along lines related to Product Features when it is Product related or based on Stages in a Process.

For example, If you are Boeing building a plane, I can imagine that you might want to know every Item related to assembling the fuselage, or maybe another grouping associated with wing assembly.  Within wing assembly, I would also want to see all of the sub components that go into it, and I might want to be able to query and instantly see only things related to a specific sub-component of work.

To make things more complicated, it’s common to also want to search for the same thing along different lines, which implies a different grouping.  Continuing our plane example, I might want to know every Item related to finishing the planes hydraulics. Since hydraulics exist in the wing, the fuselage, and elsewhere when I query for hydraulic items I will also get things that are associated with wing assembly.

Organization Needs To Be Multi-Dimensional And Consistent

So as we saw in the above example, for any given item in our project we might need to organize and identify it based on multiple potential groupings simultaneously.  In addition, we also need to be able to take a complex sub-set of items and group them into child groupings that role up to the parent grouping and we need to be able to query them at any given level of that parent/child relationship on demand.

Finally, we need those groupings to be consistently defined and applied across the whole Project or Program.

In most of the current systems on the market, this just isn’t possible causing us to try and define those parent/child relationships using complex schemas in our naming conventions.  We then augment this, where the option exists by trying to apply Tags to items as well so that we can query the Tags.  The problem is, in my experience, naming schemas are not applied consistently and the same is true for Tags.  What becomes even more problematic with Tags is that in most systems if I use the following Tags: Tag, Tags, tag, TAG the system treats them as unrelated, so when I query for Tags I only get 1 of 4 possible items that I might have wanted.  In my experience Tags, while useful in certain circumstances (and we support them in Proceve) can rapidly get out of hand in a hurry and become useless if discipline is not applied to ensure consistency.

Conclusion

Getting the organization correct for any Project is absolutely critical.  This becomes even more so as the Project or Program becomes large. 

Unfortunately, the existing tools just don’t provide much capability to support this Requirement over and above organizing items into Projects or in some cases Boards.  Even then they usually have no concept of sub-projects or sub-boards or an ability to aggregate along those lines, which would be absolutely necessary in any larger Project or Program.  Beyond this some allow a Category and Tags, but usually only one Category and they are not hierarchical so you can’t query sub-assemblies, etc. using this mechanism.

Overall the organizational capabilities of the existing systems are, as I mentioned at the start, simply inadequate.

In the next article, we will talk about the challenges existing systems have with Change Management.