This post is a follow up on one of the points Dave mentioned in his interview last week. When we where discussing hierachical projects, he mentioned that having the ability to nest projects wouldn’t be off much use to him as most of his projects tend to only last a matter of days or weeks, so aren’t the sort of scale which would really benefit from this. He did mention a possible alternative, which would be much more useful which he referred to as “cross project viewing”.
He then went on to explain it using the following example.
such as the design of a site and system for the site. May have things like different developers or even different clients. But can still have the option of tasks that span the two, etc
It turns out Dave wasn’t the only person to think having related/linked projects is a good idea. In my interview with Sundeep, he mentioned he’d make use of both nested projects and the ability to have related projects.
So now that I know it’s a good idea, I need to think about how it would work within the system, what constraints it should have etc.
Should all relations be bi-directional? As there isn’t a clean cut hierachy in the same way there is with nested projects, if project A is linked to project B, does that automatically mean that project B is linked to project A? In most cases, it would make sense for the relation to be bi-directional, but there may always be a case where you only want the link to be in a single direction. This means it would need to be a setting per project relation, although it would default to bi-directional.
Next thing to consider is what restrictions there are on related projects. Can you oly relate project with the same client? Or can you relelate any projects within your account? What about spanning multiple accounts? The problem with spanning something across accounts is it opens up a whole host of potential privacy issues with who can see what data. The same can be said about spanning several clients.
That being said, there are no privacy issues with just having a related project between account/clients if the user is part of both projects.
Linked project – The 2 projects are related (selected) with information spanning both projects. Can be one way or bi-directional. Are restricted to linking the same account and same client. The rest of this post will focus on this type of relation.
Related project – The 2 projects are related, most likely because they’re the same type. This will allow you to easily jump between projects which may have similar attributes, but without the data spanning both projects. These can be linked accross clients and accounts assuming the user is in both accounts.
Now that we’ve established what project relations can span and in which direction, I need to think about what information should span these projects. Obviously if everything is shared accross both projects, and the relation is bi-directional, it will desult in a clone of the project, and seeing as they’d have to be the same company and client (but not the same people within those accounts) as discussed above, this would be pointless. So should it be possible to have any item span both projects, but making the person creating the item decide if it should be linked? This might be a good approach, but is always extra effort for the end user, and effort is bad!
The problem with the above approach is it encourages/allows you to share too much. Now sharing is a great thing most the time, but it will create a lot of duplicate content, and create “noise” for most users, as it’s stuff they don’t nee to know. So the solution is to restrict what can be shared. Milestones and files are a good place to start and optionally messages. Tasks and tickets are too project specific and time entires will most likely be project specific (although maybe a merge for the reprts would be a good idea, but thats for another day).
Now that linked projects is all taken care off, it begs the question, are nested projects actually needed? If a relationship was to be in one direction, it implies the hierachy so you get the same end result but it also allows more flaxability. If on the other hand you kept nested projects and had linked projects, then what happens when you link a nested project with another one, then who sees what, and how much of the nested project gets shared between the 2 parent projects?
What are your thoughts? Is explicitly having nested projects a waste? Could the shared/linked/related projects be done more elegantly, anything that should/shouldn’t be shared? Let me know in the comments.
