Haven't you already faced some concerns from your customer such as: I have Planner, Project and also an action list in my project site... Which one is intended to track what??
Indeed this is a good concern. Without a clear guidance, what is at the beginning a relevant cohabitation of complementary tools can become a huge mess of redundant applications which leads to maintain a large amount of irrelevant data and thus loose sponsors and users adhesion. Garbage in, garbage out!
Which makes me talk in introduction about granularity and schedule type. The granularity is a key factor of success regarding the project weekly updates. Indeed, if the granularity is too much detailed, the project plan will be tedious to update on a regular basis and team members will have a long list of activities to update in their weekly timesheet. On the other hand, the granularity should be detailed enough to allow the project manager tracking with the appropriate visibility his project plan. Here is a recommendation (I say "a" because this is only based on my own experience). So granularity should be what helps you choosing a tool for each need.
- I do recommend to update a project plan in Project Online with an average of 200 tasks on a weekly basis (steering plan). It is handled by the project or program manager and should stay at activity level such as “specifications” or “chemical testing”. Activities should be between 5 and 20 days (duration), which will also make lighter and clearer timesheets for team members. This steering project plan is mandatory and dynamic.
- The project manager might need to establish at the project start (during the planning phase) a very detailed project plan in order to have a clear vision of the effort and task sequencing and milestones. In order to achieve this purpose, a definition plan might be created at this time, which might contain a lot of very detailed tasks. This plan is a “one-shot” standalone plan, not meant to be updated once the execution starts. Consequently, it should not be managed in Project Online but locally by the project manager (MS Project) and will be the starting point for the steering plan.
- Finally, as the steering plan might be too high level to track daily work, a task management application might be required. The task management should not be held by the project manager but by a work-package leader such as the engineering lead. It consists in a backlog tool to track team tasks which cannot be managed at project level. Many tools already exist and can be used for this purpose. Nevertheless, I do recommend Microsoft Planner, a task management solution part of the Office 365 ecosystem, in order to keep a consistency in your IT ecosystem (and also because we might one day have a connection between Planner and Project).
Another 4th item could have been added: actions or to-do's to track at project level such as "calling the provider to confirm the delivery date" or "booking a room for the executive committee". Those actions are not tracked in terms of duration or effort, but just simple tasks which must not be forgotten, thus recorded somehow. The project site action list should be the place for that.
Here is how it could be designed:
I do understand that it might seem tedious, but as soon as the guidance is clear as well as the responsiblities and accountabilities, everybody will understand and follow the best practices and all information will be tracked at the right level in the right tool.
In term of tools, we could summarize with the following recommandations:
- MS Project should be used to build a detailed project schedule in the initial planning phase. This plan is a "one-shot" exercise and will not live during the project execution,
- Project Online should be used by project manager to track project high level activities between 1 and 4 weeks, on a weekly basis,
- Planner should be used by technical leaders to break down those activities into smaller technical tasks to be updated on a daily basis,
- Action list on the project site should be used by the project manager to record and follow project actions assigned to members, which are not technical but rather related to the project management area.
Once more, there is not a unique model and it does depend on a lot of parameters: culture, maturity, business, IT ecosystem, etc. For example, a technical project manager might hold efficiently a detailed project plan without requiring the usage of a backlog. What do you think? I'd love to share your thoughts on this.