Imagine for a moment you've moved a few thousand years back in time and you're browsing your tablet (clay tablet, of course) for job offers. As an experienced project manager searching for a suitable challenge your eyes are pulled towards an interesting ad:
"A large private corporation is looking for an experienced project manager to run top projects in the most modern city in the world."
Amongst the usual requirements for that time are:
Strong communication, presentation and persuasion skills
A thorough knowledge of project management methodology
At least 10 years experience in town planning - experience in ziggurat building a great advantage
The ability to deliver outstanding performance even under exceptional circumstances (rebellions, epidemics, floods, acts of war)
However, one particular one stands out from the others:
A good knowledge of at least 50 of the 73 local languages.
This is not a common requirement today and probably wasn't common even at the time of the Babylonian empire. But as we know from the Bible (Genesis 11:7: “Go to, let us go down, and there confound their language, that they may not understand one another's speech.”), God punished the Babylonians for their pride and solid language skills were a necessity at that time :)
How a project manager could have possibly delivered a structure as demanding as the 91m high ziggurat Etemenanki if he hadn't understood his team, its subcontractors, HR department, PR department, end users, testers, project sponsor or his boss is hard to imagine. And when you consider the number of different languages he would have needed just for the agenda of his regular SCRUM meetings or how many he had to produce the weekly reporting in, for both client and employer not to mention his presentations to the project's steering committee - well, I think you can imagine both the scale of the task and the depth of the frustrations he faced!
Aren't you happy those times are over ............ or are they?
The truth is that you mostly get by with one language today. Unfortunately, that doesn't mean that we only need one version of an agenda or one version of a status report when we're involved in project management. The situation, as we know, in the corporate environment, is slightly different.
We have one agenda for meetings with our team where we go through the status of critical tasks needed for project delivery, including those which don't need to be mentioned to the customer. We set deadlines and responsibilities. We plan capacity.
Then we prepare a status report for the customer. This usually requires a different format and a different set of tasks. Therefore we re-write the agenda into the customer’s "language".
If the PM works for a software-house, he usually has a boss who he reports to, and he is probably required to report on a different set of tasks from the ones required by his team or customer. Usually these are the critical tasks that stretch across all the projects he's involved in. So we re-write the agenda yet again, this time into the "language" our bosses understand.
Finally there are the steering committees. They always require yet a different perspective on the status of the project, and let's not even start to talk about the format of the agenda. So another "language" version of the agenda needs preparing.
The irony is that in all cases, it's the same project and the same tasks that we're tracking and following. And instead of being focused on the important things that determine the success of the project, such as risk management, we spend a lot of time translating the same agenda into a number of different "languages".
There IS another way - the Semanta way
We at Semanta do this work a little differently. At the very beginning, we took the decision that every task that's worth watching will be entered into the issue tracking system. And we also decided on a high degree of openness and transparency, which greatly simplifies the problem.
We use JIRA as a tracking system and combine it with Encyclopaedia, a product we developed for the BI environment. Technically, Encyclopaedia is a plug-in to Confluence and it integrates very well with JIRA - both JIRA and Confluence being developed by Atlassian.
Once the project has been planned and the phases of its delivery have been divided into a WBS, we enter the individual tasks into JIRA. Initially these are summary tasks that will be gradually divided into individual tasks and subtasks. We use the same strategy for clients' projects as well as for the internal development of our products.
Using a professional issue tracking system allows us to exploit all of its sophisticated features for managing our projects. We find it particularly valuable that:
each task has its assignee, resolvers, priority, due date.
tasks may be linked to each other, which creates relationships between them.
a history of all the changes and comments is automatically recorded.
any change in a task is immediately reflected in all the agendas the task is presented in.
Tasks can also be enriched with metadata defined by the user, things like a "PM note" or "Affected product versions". Labels are particularly valuable in this respect. They allow the user to literally label any issue with user-defined tags, like "Internal status", "To be tested", "Backlog" or whatever.
Labels and other metadata, in conjunction with filters become very powerful tools for creating any list of tasks you might need. This is especially useful for creating sets of issues to walk through during a meeting, in other words in creating an agenda.
Fig 1. - Detailed issue with annotations of the major fields
At Semanta we don't face the same problems that the Babylonians or contemporary project managers faced or face. Once a project has been entered into JIRA, Encyclopaedia allows a meeting's agenda page to be set up, formatted and saved; meaning it is prepared once and can then be used again and again. As the project runs, whenever we look at such an agenda, we wear agenda-specific glasses (e.g. a filter specific to that meeting) and see only the tasks which are relevant and current to that particular one.
If we want to, we can even set up an agenda page with a number of different sets of tasks, all related to the project but divided into groups each with a specific purpose. For example one group might be "Tasks to be tested", another one "Tasks to be prioritized for development", or "Tasks to be postponed" or "Overdue tasks" etc. The point is, an agenda can be used repeatedly without any extra work or input once it's been set up.
What does it look like and how does it present the information?
Only the specified task fields are displayed on an agenda page. However the full detail of any task is just a click away, as the filter provides links to all the individually displayed tasks. If you follow the link, it takes you to JIRA and opens the task detail page. Here you can make any updates you need and every change is automatically reflected in all the agendas that contain the updated task.
Fig 2. - agenda page with JIRA window
One step further
But that's not all. In Encyclopaedia, we took project management support one step further. We've collected the most important parts of a project's management into a single space called an Area. Now all the important information connected to a project, things like "Questions and Answers", "Important documents", "Minutes of meetings" and the "Tasks" mentioned above are available in a single place. There will be some more info on Ency "Areas" in one of the following blogs.
Fig 3. - Area page navigation
It's simple, transparent, consistent and effective and you don't have to be building a ziggurat to use it. If you are overwhelmed by God's wrath and a multitude of languages or simply by the demands of managing a complex and rigorous project, just put all your tasks in JIRA, design your agenda's layout in Confluence or even better in Encyclopaedia, and enjoy the synergy. And you're always welcome to contact Semanta if you need more courage or support to do so.