As a project manager, I’ve been always researching about the fittest tools to manage my projects. I regret wasted time because unproductive tools. For me this is a bad practice that needs to be avoided. We project managers are expected to meet the project management goals. This means finishing the project on time, on budget, delivering the committed scope, meetings stakeholders’ quality criteria, etc. When a project fails, every manager is going to blame the project manager, this is why we exist…
If the project does not meet the project management goals, and I am the project manager, I know I am the one to blame.
But when a project fails, no project manager would blame tools, even if the team wasted a lot of time because of unproductive ones: plenty of emails, too many meetings and useless reports, lots of paperwork documenting changes, time sheets and expenses, micromanagement on planning and estimating low level tasks or nonrealistic activities, etc.
So, when I discovered some tool that could save us time, or enhance collaboration, I’ve always tried to use it. If the tool were not used yet in the organization, or I was kindly advised to use other instead, I made it to get it into my project. When I said “I get the blame if the project fails, so I decide on project tools” most of my bosses said “ok, deal”.
Now that I’m working in project management consulting industry, I feel I’m compelled to keep that habit of tool researching. I fear of missing out any good project management tool. When I hear about a new tool, or new features in tools I know, I have the habit of processing that piece of information. This is now easier because of the good benchmarking resources available, especially video tutorials by tooling experts. I’ve also discovered many tools through students, colleagues, customers and friends.
Steven R. Covey said that we need to stop sawing the tree and devote time to sharpen the saw. Now and then we project managers need to think about the tools we use. Will I do better on my next project if I change tool A for tool B? Sadly, we cannot answer this question theoretically. In projects, we take decisions on tools by practice.
Currently I am managing a project to create a new software. We will launch this as a freemium product, named PMPeople, so that all people needing to collaborate on projects would do that using their smartphones. We outsource software development to a software factory in India using Scrum. We communicate mainly with the Product Owner. They assign us a Scrum Team of 3 programmers and the Scrum Master. Some mornings –at 7 a.m. in Spain, 10:30 a.m. in India- we meet by videoconference to solve impediments, clarify requirements and see demos. We keep communication alive through Slack and collaboration through Asana.
In the chicken and the pig story we would be “chicken”, keeping the roles of project manager and business analyst. We say what to do, not how to do it. We think it is important that we keep this functional, management role.
This is by far the most risky project I’ve ever managed. This is mainly because of the software, not too complex but having a lot of business rules applicable to the 11 type of users possible connecting via web or mobile, and also with a lot of integrations with other tools for scheduling, instant messaging, task management, document management, change management and CRM. Since we need to grow through virality, we will have to validate business hypotheses applying the Lean Startup method. Above all, having no external financing, we have to use our own funding.
Now that I am the boss, there is no debate on tooling ;-). Since May of this year we have produced two releases and now we are beginning the third. We practiced a lot on tooling and now I’m happy with the results. At this point, I think I’m certain on what tools should I recommend to any project manager managing software projects.
Below you can see the tools we are using to manage this project. I don’t include the software development frameworks for web and mobile and other products used by the factory for software configuration management, test automation, continuous integration, etc. I will mention only the tools that we are using for project management. These tools can be classified into 3 levels:
- PROJECT GOVERNANCE: This level includes those tools to provide high level reports to steering committees, PMO, etc. The right information aggregation at this level is the Control Account. Using this information summaries on cost, schedule and scope, we have to explain project variances and forecasts, propose preventive or corrective actions in order to finish the project achieving the management goals. On this particular project we don’t need many tools at this level, maybe only the risk register. You can download the excel template here.
Keep in mind that PMBOK® is a framework, not a methodology. It tells us what need to be managed, not how to do it. When we apply Scrum, the project management framework is still applicable.
- PROJECT MANAGEMENT: This is the project management level, properly. When we apply an agile lifecycle model, we still need to apply the PMBOK® framework to decide what to do to finish on time, on budget, with stakenolders’ expectations met. Remember that PMBOK® is a framework, not a method. It tells you what need to be managed, not how to do it. We can use Scrum framework on the technical level –3 roles, 3 artifacts, 4 ceremonies- but we still need the project management framework on the management level. Regarding tools, later on I will describe the ones on requirement management. With respect of scope, schedule and cost management, I aggregate all the information in Microsoft Project®. For the lowest level of the schedule we use the term activity, not task. I prefer to use tasks on the project work level (see below). I feel I reach the right level of decomposition when I convince myself of this: If I monitor activities and milestones dates, then I can manage the project finishes on time. If I decompose lower then I will fall into micromanagement. In order to represent control accounts in Microsoft Project, I use a Timeline having the control accounts and also the most relevant milestones. Project governance people will have all the schedule information they need just if I copy the Timeline and paste it to a project status report. In agile projects, my activities are at the sprint level. Summary tasks represents the release level, which I identify as control accounts. When I use Tracking Gantt view I can see performance against schedule baseline, variances and forecast.
- PROJECT WORK: The meaning of task is the elementary work assignable to a team member. We use Asana as our task management tool. We see the lists managed by the Product Owner representing the product backlog and the release backlog. Factory guys use another list –and also a kanban board- for the sprint backlog. They don’t use these lists to manage their own low level technical work, only the work visible to us, i.e. the user stories and the tickets we put, so we use Asana as our defect ticketing tool as you can see in the image below.
Now I want to mention which tools we are using to collaborate at the level of WORK MANGEMENT:
- We use Slack to communicate with the Product Owner through instant messaging. We tend not communicate with the software factory by email, only for billing and formal things.
- To track defects we can include a short video captured with Jing or a screen shot with LightShot –both tools allow cloud storage and url sharing.
- For videoconferences we use GoToMeeting, since we pay for it for our live internet courses. If not for this, we would probably use Zoom.
Finally, I’m introducing how we do requirement management or business analysis. Our way to keep the functional control on the requirements is based on these traits:
- We maintain 2 PDF files as our walkthrough prototypes developed with Balsamiq.
- We maintain the data model specification using a CASE tool named ERwin, which allows us to divide the schema database into several functional modules.
- We use Microsoft Word® to maintain the functional specification, which is our kind of contractual agreement, and another documents for the customer journeys. These functional documents change a lot. We keep one single version shared through Google Drive.
See below and image taken from our functional specification document:
And finally, here you are an image of our pdf walkthrough mockups:
Update: Going on with this post, last 30 October 2017 I was interviewed by Yegor Bugayenko, who is the host at Shift-M weekly podcast. You can listen the recording here.
