Project management is a complex combination of many disciplines. A successful project manager becomes adept to juggling all of them. Each discipline is used in a balance for successful project outcomes.
Organization is one of the key disciplines of project management. A successful project manager needs to have an organization system that allows them to know everything that is happening. This includes a proper to do list, organized around the meetings of the day. To do items should be prioritized to ensure the right things are being done at the right time and in the correct sequence.
Another important aspect of being organized is being prepared. The Project Manager should prepare for every meeting. This means verifying that the right people are included. Regardless of whether you organized the meeting or not, prepare like you will need to run it. Have any documentation that you may need handy. Be aware of the purpose of the meeting and the agenda if possible.
President Dwight Eisenhower, who as a general planned the D-Day invasion of France during World War II, famously said, “Plans are worthless, but planning is everything.” It is true that as soon as you have a plan documented, things change to that plan. But the process of planning allows you to document and communicate to the team what the desired outcome is. It sets a baseline for everyone on the team. The plan will change frequently, perhaps on a daily basis. But you will adjust your assigned tasks, the schedule, and the project priorities based on that baseline and the changes that occur.
Agile project management has enabled us to move away from the Waterfall approach of a detailed project plan, with lists of tasks for the duration of the project. We now have some idea of our ultimate destination through our backlog. We can then plan in short term (usually 2-week) increments. This allows us the flexibility to reprioritize without making drastic changes to a plan that quickly becomes obsolete.
This does not eliminate our need to plan, even if it is only for two weeks at a time.
We can define the scope of a project with tools such as a Statement of Work or a backlog of tasks. As business needs and priorities change, the scope becomes as fluid as a river. The project manager needs to keep a close watch on new requirements and decide whether it is a change to scope.
The standard tool used is a change request. Change requests allow the project manager to document a change and provide details on how that change will impact the project. It may increase or decrease the effort. It may affect the final cost or the project end date. Once all of this is documented, it is presented to the project owner for approval.
If it is approved, the change can be included in the current sprint with some re-planning or prioritized in a future sprint.
Not every change requires a change request. Some are small and can be absorbed. Project owners do not want to receive multiple change requests for minor changes. This can become a slippery slope though. If you let a few “minor” changes go through, it becomes “scope creep,” where you have included significant functionality without managing the cost.
Changes can also be the subject of interpretation. Based on how specific some business requirements or stories are written, business users may have a much different interpretation of what is included than the implementation team. This can create some confrontation. It is the responsibility of the project manager to facilitate these disagreements and come to the final conclusion of how it will be charged and managed within the scope of the project.
In an agile environment, most team members manage their own tasks. The project manager should ensure that the tasks are on track in the daily stand-up meetings. The project manager should also ensure that the dependencies between tasks are managed as well.
When tasks are dependent on others, the tasks need to be managed to prioritize the upstream tasks first. If there are delays in those tasks, there will likely be impact (i.e. delays) to the downstream tasks that are dependent upon them.
Delays like this can send projects off the rails and into significant delays. Paying close attention to all tasks and their dependencies can keep the project on track.
Risk and Issue Management
I have always said that an issue is a risk that came true. Risks are things that could go wrong in the future. Issues are things that did go wrong. Managing risks is a proactive way to manage issues.
Risk management includes identifying anything that could go wrong, assigning a likelihood of its occurrence and what the impact would be on the project if it occurred. Depending on the likelihood and impact, you may want to develop multiple mitigation plans for its occurrence. Then if it becomes an issue, you have multiple routes that you can use to manage it.
Issue management is more reactive. If you identified this issue as a potential risk, you may have plans in place to deal with them. Often times, the issue was not anticipated and therefore, not managed as a risk. In these instances, you need to develop a plan to deal with the issue. If the issue is serious enough, you may need to escalate it to a higher level of manager for help in resolving it, or simply to make management aware of its existence.
The original budget will consist of all purchases made for the project as well as the cost of personnel, usually measured by billing rates times hours worked per team member. Assuming the team members enter hours on a weekly basis, the project budget should be managed at least on a weekly basis.
Track total expenditures for the week and calculate the percentage of the project budget that has been burned. The percentage burned will not always equal the percentage of the project that has taken place. However, any differences in the percentage burned of the budget to the percentage completed in the project should be able to be explained.
The project manager will generally deal with several vendors. This can be for equipment or for staffing through consulting or staffing firms. A good project manager should develop skills in negotiating with these vendors to ensure the lowest possible cost is being incurred.
This extends beyond the initial transaction. Once the price is agreed upon, if the value or duration of the goods or services are not up to expectations, the project manager should continue to negotiate for better terms or possibly even refuse payment.
While process definitions are usually attributed to business analysis for business requirements, the responsibility also falls upon the project manager. The PM needs to be able to define any process steps for the project and communicate it to all project stakeholders.
This can include how to communicate with business stakeholders or procedural issues such as time sheet and expense report submission. A project Wiki is often a convenient place to record this procedural information. It needs to be culturized within the project that that is the place to go for any information the team needs on procedures.
In addition to a Wiki, processes and procedures should be communicated via multiple channels. This includes reminders during team meetings and email announcements if any changes are made to a process.
There is a lot to managing a project. Whether you are managing a project using Waterfall, Agile or some form of hybrid approach, all of these will be used. The topics discussed here are only a small number of key disciplines of Project Management. There are hundreds more that you will likely use on a daily, if not weekly basis.
What are some of your favorite key disciplines of project management?
If you would like to learn more about a career in Project Management, get Lew’s book Project Management 101: 101 Tips for Success in Project Management on Amazon.
Please feel free to provide feedback in the comments section below.
Image courtesy of kdshutterman at FreeDigitalPhotos.net