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.

A project is a temporary endeavour, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables), undertaken to meet particular goals and objectives, usually to bring about beneficial change or added value.

The above definition of a project is taken from Wikipedia, and does a good job of summarising what a project is. At its most basic level, this application will help to complete these projects in an efficient manor by bringing together all the people involved in the project into a centralised system, where they can easily collaborate, share resources, track deadlines etc. What functionality is included as part of a project will be described in the appropriate sections, but I will outline some of the project specific functionality.

Projects can be nested

This is something which seems to be lacking from a lot of web based project management systems, but is requested by a lot of users. A project can have any number of sub projects, but each project can only have 1 parent (a top level project has no parent project).

Only one company and client account per project

At first, this may seem like a limitation, but this “limitation” combined with nested projects makes sense. If you have a project with 2 or more companies working on it, one of those companies will be leading the project. In this case, the lead company controls the top level project, and the second company is a sub project which has the parent company as its client. This even works for very complex project structures, as you can have the hierarchy of any width and depth, but at each level, there is always a company in charge of its sub hierarchy.

Projects, do it your way

Everyone manages their projects differently, so the PMS will not force a given system onto you, but aims to be as open as possible, so you can do it your way. One example of this is with deadlines, as mentioned in the opening definition, most projects are completed to a deadline, but not all of them, so this won’t be a required piece of information, although giving it will provide added value.

As mentioned earlier, the main purpose of the project is to act like a container, so it can group relevant data together, which will be discussed in more detail later.