Minimalist Project Manager

The word "minimalism" means "a style or a technique that is characterized by extreme spareness and simplicity". Minimalist is someone who uses 'minimalism' as his style of working. To do a good job of managing a project, a project manager needs a solid work plan. The work plan lays out the tasks and activities that are necessary to achieve milestones during the course of the project. Once the work plan is created, it gets (needs to be) tweaked throughout the life of the project to reflect the current situation and future opportunities or risks. Its very often the case that the project manager keeps track of every single task (in terms of planned and actual completion) to track the progress of the project. This process is usually time consuming. In practice, the project manager should focus on the critical path and the tasks/activities that have a direct correlation to those tasks and activities. In addition, the project manager should share these set of milestones with the core team on a weekly basis to keep them focused on those activities. We know that the critical path changes during the project, so project manager should tweak the tracking accordingly and keep his team focused on the altered critical path. The management of tasks at detailed level does not go away, because the core team will start owning the tasks that contribute to the critical path milestones.
As they say 'don't fix something that's not broken'. The project manager should focus on those exception situations affecting the critical path adversely. This is the role of a minimalist project manager. The minimalist project manager identifies those exception situations, elevates those to the right levels by focusing on those and addressing those swiftly. These may have an impact on critical path, which, the project manager would communicate to the core team and all stakeholders.

Bite sized communication

In todays world, where we are inundated with information from several mediums - social networkig sites, blogs, internet, and communication at work, people are unable to keep up with the information that they need to make good business decisions. Several emails are not read on a timely manner,and when things are changing fast, these become outdated very quickly. It seems that information that needs to be communicated in executive reports, should be bite-sized. It should be at a fairly high-level, and should be embedded in the body of the email itself (with links for detailed information). A report that typically fits on one PDA screen without having to scroll, is most likely to be read, and actioned. This gives the executives sufficient information to stay abreast of things in-progress and check the details, on an exception basis.

Inspire a shared vision

Majority of projects that a company undertakes has goals and objectives that support one or more strategies of the company. As we all know, every company executes strategies to win in the marketplace and realize its vision. So, on a project, it is the responsibility of the project sponsor and the project manager to clearly define the purpose of the project. It is very likely that if you ask people who worked hard on a project, if they knew the purpose of the project they worked on, you might get a quizzical look. One of the most common responses to that question is "I did what I was told to do." I feel that this is a failure on part of the project sponsor and the project manager (to certain extent) that the team members are uninformed or unaware about the objectives of a project. On those projects, where the team members are clear about the objective(s) of the project they are working on, they tend to be more committed. There is a sense of pride that the work that they are doing, is creating value for the company. This helps the project team members stay positive even during difficult times. They are more willing to go above and beyond to make sure that the project is successful. In order to make sure that every team member fully understands the objectives of the project, the project sponsor and project manager and their team leads need to continually communicate the vision. Every project has team members that are on-boarded throughout the life of the project, depending the needs of a specific phase of a project. So communicating the vision just once, at the beginning of the project is not sufficient.

Managing part-time resources

As a project manager, you 'play the hand you are dealt' in terms of managing resources, among other things like scope, cost and schedule. The ideal scenario for the project manager is to have the right resource available at the right time, and be 100% productive from the get-go. Several project managers make this assumption when they are planning work, and then have a rude-awakening when the actual output/progress is slower than expected, often times because the productivity is much lower. This is even more apparent, when a team is comprised of some full-timer's and some part-timer's. There are couple of key assumptions that need to be addressed in managing part-time resources on the project:
1) Say it takes 8 hours to perform a job by 1 person, which requires some thinking and then doing. It is a bad assumption to make that if the same person works on the job in say two 4 hour chunks, on two different days, the work will be complete.
2) Full-time resources on the project that need help from part-time resources, assume that part-time resources are available as and when needed. This again, is a bad assumption

Part-time resources are working on more than one project, and hence multi-tasking. We have often heard people say that they multi-task very well. However, several studies have been conducted to prove that wrong. Put this in context of a resource working part-time on two projects, in order to switch between performing tasks on two different projects, a 'switching time cost' is incurred. Depending on the skills required, sometimes the switching cost can be significant. Consider this: Say a project resource is doing a mundane support task one week, and doing project work the next. He is thus available 50% of the time to the project. Say a resource starts working on a task in week 1, does not finish it in week 1, and then has to start working on it in week 3 (because in week 2 he is doing a mundane task), how realistic is it to assume that in week 3, the resource will lose no-time and have the same productivity as he had when he was working in end of week 1? So a task taking 80 hours (2 weeks), more often than not will not be completed in 2 weeks in the above mentioned scenario

As a project manager you need to plan for some buffer when utilizing part-time resources. Unfortunately, its not an exact science, because different individuals will have different 'switching time cost', so to plan for it requires some judgment. Also, it is a good idea to get a better understanding of vacation time or any other time off the project, especially in case of part-time resources. It is the project manager's responsibility to set expectations of the full-time resources on the project that they need to work with their part-time counterparts to plan the work better for optimal productivity.

Project RACI

RACI matrix describes the participation by various roles in completing tasks or deliverables for a project or a process. A Project Manager should always create a RACI matrix for a project and share it with the team at the project kick-off. This helps in clarifying the expectations of the entire project team, including project manager and thus mitigates the risk of 'lack of ownership'. The project manager should take time to educate those who are not familiar with a RACI matrix. Also, team members are added during the course of the project as well as new roles are defined for the existing team members. In these instances the project manager should again clarify how those individuals/roles fit into the RACI matrix. Thus creating and sharing RACI is not a one time activity, but may need to be used as a means of communication multiple times during the course of the project
The projects where this tool has been used and well understood by the project team, there have been fewer gotchas in terms of 'who does what and why'. Project manager can harvest the benefits of this tool throughout the project

Great project plans do not assure accurate project status reports

Often times it is seen that a project starts with a good project plan created using Microsoft Project. After all, it’s a project management best practice to have a project plan. It’s a misnomer though that if we have a good project plan, the plan will show accurate status of the project at all times. So, if a senior management needs to know about the status of a project at a high-level, the project plan can provide that information.

It has been observed, on multiple occasions that as the project activities start happening, the updates to a project plan starts to fall behind. Some tasks are updated with % complete, however, actual start and finish dates are not updated. If the project manager is has not set his team’s expectations about requiring an update about progress of their respective tasks from them, he may get updates from some but not all. Thus the project plan update is incomplete and inaccurate. Also, if a project is 50% complete, doesn’t always mean that the remaining 50% will take twice the time already expended.

Creating and maintaining a project plan requires discipline. The project manager should set aside time each week to make those updates. Otherwise, the updates are often not made at all or made in an ad-hoc manner. The updates should include % complete and updates to actual start and finish date fields. In case the finish date is likely to be pushed out, the project manager should make that update.

knowledge harvesting is so hard!

Typically, documentation which is one of the means of harvesting knowledge on a project gets the least importance as the project nears completion. When any project starts, every project manager lays emphasis on knowledge harvesting and yet its importance diminishes as time goes by. Why does that happen?
One of the reasons is that people believe that documentation needs to be done at the end. As the project nears completion so much has transpired and documentation during the course of the project is in emails, in post-it notes, and people's brains that it is impossible to convert that into documentation that is coherent and meaningful. As a result, even if sufficient time is allocated at the end of the project to complete documentation, the documentation that is created is incomplete, lacks context (why certain things were done) and becomes merely an academic exercise
The consequence of incomplete and insufficient documentation is that the product or service created as a result of the project is not easily maintainable thereby increasing the total cost of ownership (TCO).
Project manager can take some simple steps to circumvent this problem:
1) Take bite-sized-documentation approach - document things as they happen without having to re-write. Provide a control mechanism to measure whether this approach is working and that the documentation is leverageable.
2) Do not take a one-size-fits-all approach - depending on type of project and its duration, different types of documentation may be necessary. Being pragmatic will ensure good documentation and team members will be more willing to complete documentation
3) Always use a central repository to store documentation - sharepoint, project wiki, etc. are good options. This eliminates the need to have to bring it all together towards the end of the project