Projects – A Process of Change
This is because of the inherent instability of projects. They are a process of change. They are creating a new product, process, facility, or system. They are building up or tearing down. They are modifying, improving, adapting, or upgrading. Projects are all about changing the status quo. And when there is change afoot, there is instability and uncertainty. Ignorance of the change does not protect someone from the impact of the change. Ignorance is not bliss, it is project disaster. Wisdom is not folly, it is vital for recognizing and reacting to changes.
Now you may be thinking that the instability and uncertainty could result in a better than expected condition. Bliss may still occur by accident. The project may go much faster than expected. Things may work better than expected. The cost may be lower than expected. But the problem with those conditions is that phrase, “than expected.” The business is expecting a certain level of project performance. The change that the project brings about will impact the organization. The business leaders are aligning the rest of the business processes and systems to accommodate that change. Finishing the project with anything other than the expected level of performance will cause a misalignment and some corresponding negative business impact.
Assume Nothing Is Certain
Wisdom is needed on projects. Socrates said, “The only true wisdom is in knowing you know nothing.” That is accurate for most projects. With the inherent uncertainty of project activity, the project will not go as planned. The project leader and project core team members must be continually monitoring project activities and deciding when and how changes should be made to the project plan. Don’t assume that everything will happen as planned: Check on it.
This may sound like micro-management. It is. But it is micro-management only in the sense that you are checking frequently to understand what is happening, not that you are continually over-riding the decisions of team members or directing them on how to do their job. This type of micro-management is a frequent pulsing of project activity to uncover roadblocks, miscommunications, misunderstandings, and project problems. The project leader will then work to correct each of these.
I recommend the use of project pulse meetings. These are frequent regularly scheduled team meetings. I know, you are saying to yourself, “We already have too many meetings! I can’t add one more.” These meetings will ultimately reduce the amount of time spent in project meetings.
I hold project pulse meetings every day. The meeting lasts about 10 minutes. These meetings are not long technical discussions and status reports, these are a quick check to find problems. My agenda for these meetings is very simple:
- Did the tasks that were supposed to finish yesterday finish? If not, what do you need to get them done?
- Did the tasks that were supposed to start yesterday start? If not, what do you need to get started?
- For the tasks that are underway, have you uncovered any roadblocks that will prevent you from fully completing the task on time?
Typically there are only about 10 active tasks on a project. It takes less than a minute to answer these questions for most tasks, so the meeting is done in 10 minutes. Then the project leader works offline with the appropriate task leader(s) to understand any problem that was raised and develop a solution.
This type of Pulse Meeting lets everyone on the team know if something is ahead or behind schedule. They also will know the major issues the project faces. This type of proactive knowledge allows the team to act wisely. They can decide to ride a problem out, add extra resources or attention to a problem, or change the project plan to avoid or accommodate the problem. Thanks to the Pulse Meeting, the project leadership is not ignorant of problems. They can proactively respond to them while they are small and reduce the need for crisis intervention or project failure.
I have conducted these meetings both in a face-to-face manner when the project team was essentially co-located and in a virtual manner when the project team was distributed across multiple locations. I set the meeting to be at the same time and place each day. And – this is vitally important – I cap the time, usually at 10 minutes.
I have found these to be far more effective than weekly one hour team meetings. In those meetings, we often don’t find out about a problem until it is already 4 or 5 days old. By then, it is often impossible to recover back to the original budget or schedule. In addition, these often turn into a forum where each person is talking about everything they are doing, but we lose sight of whether tasks are starting and finishing on time.
Pulse Meetings pull back the veil of ignorance and allow the project leader and team members to act wisely.