Top 10 Activities for Project Managers

In today's world, project managers are responsible for an increasing number of things. While this shows progression in the career and growth of the project managers, we need to remember the core activities that project managers are accountable for. These activities are activities important to the success of the project and of the team, however I am increasing seeing organizations prioritize reporting, data gathering, and office politics over these critical activities.

1) Act as the Communication Hub
In my opinion, communication is the most important thing a project manager can do. As the communication hub, the project manager gathers all of the relevant project and team data together and parses through it to provide a concise and clear message to the team, stakeholders, and management. Dissemination of this information is up to the project manager and the organization, but the actions of the most skilled communicators are easily verified by asking any stakeholder, "how is project X doing?" If they have to pick up the phone and call the project manager, this area needs work.

2) Collect and Review Documentation
When it comes to documentation, let's ignore the discussion of valid and necessary documentation for this blog and rather say any documentation that has been deemed "required" is necessary for the project manager to collect into a central repository and review/confirm complete. This is to say the project manager is not responsible for the content, but rather the storage and existence of the document.  Often times, documentation is pushed to the sideline in favor of delivery, when this happens the project manager should track and ensure completion prior to completing the project.

3) Facilitate Meetings
Project managers are not necessary in every discussion that occurs on the team, but it is the project managers responsibility to facilitate the meetings. Facilitation is not simply taking notes, but rather prepping an agenda, ensuring the right audience, driving the teams to value adding conversations, and a little bit of note taking at the end. Why you ask, see item 1. When a team is not communicating effectively it may become necessary for the project manager to step in and force the communication. This may be in the form of daily standups or weekly status meetings. One of the best ways for a project manager to force communication is to put the team into a meeting and FACILITATE it. Proper facilitation will also drive shorter more effective meetings, but more on that some other time.

4) Lead the Team
Leading a project team is not always easy, but it is critical that the project manager not simply drive for tasks to be completed, but really lead the team forward.

5) Ensure Follow-ups are Done
Without this activity, things "fall between the cracks" and commitments don't get met. The project manager should track these actions and make them part of the project plan. Most of these types of follow-ups are

6) Resolve Conflict
Over a long enough project, you are bound to find conflict in the team and/or with management. The project manager should take an active role in reducing and resolving this conflict.

7) Look Out for Roadblocks and Issues
Part of our role should be to identify any broken, inefficient, or ineffective processes that we encounter in our day to day. These items cause a problem and potential delays in our projects. We may not always be able to correct the inefficiency but at the very least we should be documenting it in a lessons learned. However, when possible we should be driving for correction. After all, if it is a problem for you and your project it is a problem for someone else as well.

8) Process Improvement
Project managers are in a unique position to see processes that effect delivery of a project. Sometimes process changes seem benign but when applied at the project level, result in a significant impact to the project deliverables. As such, the project manager needs to advocate process improvements from this perspective.

9) Continually Look Ahead of the Team
As the project moves through execution, a critical part of the project manager is to remove roadblocks and impediments for the team. Looking ahead will allow the project manager to remove these roadblocks before the team gets there. Think of it like this: The team is a locomotive moving down the track. If you slow it down, it takes a lot of energy (brake power) to slow the team and then it takes a lot of energy to get the team moving again. So any work a project manager is doing before the team gets there, will go a long way in keeping the momentum.

10) Act as Marketing Department for the Team and Project
Bad news travels fast, good news (or team successes) can go unnoticed. Why is that? Because when something goes wrong, someone, typically management, has to get involved to provide corrective action, whereas a success required no additional work or action by management. The project manager needs to be in front of management, customers, and stakeholders championing the successes of the team and leading the celebrations. Doing this well, increases moral, teamwork, and leads to greater outputs in the future.

I would love to hear from everyone else, what are the top critical activities you want/need to see from project managers? Project managers, what are the things you do that you feel are the most valuable? Is anyone feeling the pressure to spend time on things like office politics instead of your project? What are the things and how do you handle the request?

Driving Process Improvement as a Project Manager

The primary delay in companies today, are processes that don't align with the work being done. This happens for a variety of reasons from the process being out of date to well meaning poorly implemented changes to a process.

As a project manager, we see the effects of these ineffective, inefficient processes daily. We see these things when our projects take longer, we have dependencies where the work waits on the process or things are delayed for an artificially imposed dependency. To improve our chances of success and the success of other projects in the company, we should be identifying and working to resolve these process issues as they are identified and outside of the flow of the project.

If there is not a process improvement team inside your organization, the PMO is a great a place for this responsibility. If you work in an organization that does not have a formal PMO, I would suggest taking the initiative to spin up a pet process improvement project led by the project manager. This should be something that goes through a formal SDLC with requirements gathering, prototyping, development, and analysis after the change. Many people will talk about the DMAIC process most well know for its place in Six Sigma which is a great process, but may be overkill depending on the size of the process you are trying to improve and the maturity of your organization. As such, unless you have a formal process improvement team, committee, or initiative I recommend the approach below.

If you don't already have some areas that need improvement, start with looking at your current processes.I have found the three areas below to typically be the areas with the largest opportunity for improvement. When evaluating them, look for places that process is driving the work rather than work driving the process. For example, some organizations require code review before the code goes to testing. This process typically takes days to get on the schedule and results in the code siting in a queue and waiting since it had to be done before the code review could be scheduled. Could you adjust the process so that code review can be requested or scheduled in the future? Could we change the code review to not be a stop and wait? Perhaps the code could continue forward to the test environment and code review could happen later (this may produce technical debt).

1. Testing
1. Is your testing automated? 
2. How do you regression test?
3. Do you have a full test environment? 
4. Who executes your testing?
2. Release Management
1. How do you migration code from one environment to the next?
2. Who is responsible for production releases?
3. What is an acceptable level of bugs released to production?
4. Are there established release windows?
3. Requirements Gathering
1. How detailed do you require your requirements?
2. Do you require a phase gate before leaving requirements gathering?
3. What is your system or approach for requirement changes?

Unless you have the support of your organization and management team, I suggest that you select the single biggest value (most time saved) and focus on that for your first process improvement and only work on one at a time.

There are entire process improvement methodologies out there that you can use to execute process improvement (Six Sigma, Lean, Business Process Improvement, etc) but here is a simple step by step for your basic process improvement:

1. Select process for improvement and create a step by step process map (example)
2. Schedule a review meeting with the concerned parties and review the "as-is" process
1. Remember that some of these people may of had a role in the creation of the now out dated process, so be nice!
3. Confirm the process as accurate and then discuss each step and what is the value of the step
1. Really drive to understand: What value does that step brings to the process? 
2. Pay close attention to why each step happens in that order. 
4. Looking at the process from delivery to the down stream process as your goal, identify how you can make that happen faster. 
1. The items such as documentation are still valid, but why can't they occur after the product or item is delivered to the downstream process? 
5. Work with the team of concerned parties to re-organize the work and remove any tasks possible.
1. For example, do you have to stop and wait for an approval or can the work continue while the approval is happening? 
6. Test small scale, with a single project for a few weeks.
7. ITERATE! Don't be afraid to carve to much off and realize that you need to add some back. 
8. Once the team is comfortable with the new process, make sure it is well communicated to everyone otherwise adoption will fail. 

Agile ≠ Fast

If you look up "agile" in a thesaurus you will see terms like: nimble, spry, zippy, and quick. However, in today's business, agile is used to describe a way of executing a project where you prioritize the highest value items of the project and work on them first. To enable this, the cross functional team works closely with a lead (product owner) from the business team, valuing the communication and relationship over a formal requirements document.

This type of project management has become increasingly popular over the past several years and "agile" has become a buzz word heard throughout companies everywhere. Originally built for software development, agile practices are being leveraged for every facet of IT and other areas inside companies. We could spend hours debating the value of agile or waterfall project management, but for the sake of this blog, we will summarize that both are valuable and have their places.

The issue has become that while agile is becoming a common term and the victories of agile processes are becoming more and more available and broadcast, management looks to implement these processes into their organizations. This sounds like a great win for the agile community and like a solid direction, but all too frequently management is taking their definition from the thesaurus and are looking to agile to complete their project faster. The reality is that agile uses iterative development and breaks work down into smaller chunks that allow the high value items to be delivered first.

Done correctly (we will define this in a future article) agile will result in high value being delivered first and then lower value being delivered later in the project. Agile will also provide the ability to quickly adjust to the changing business needs and values by allowing the scope to shift from iteration to iteration. But to truly be faster, it is the lean processes that you implement not agile on its own. These processes are frequently overlooked by management who instead focuses on this mystical all saving agile to fix their problems. While I personally believe agile offers a lot of benefits a greater benefit would be had by leaning out their existing processes before they move to agile. 

At the end of the day, agile is another way to organize and execute on the work. While agile delivers high value items first and faster, the entirety of the project will typically last as long if not longer (depending on requirement changes) as a waterfall project. To make your process faster, you have to start by evaluating your processes and working on improving them. After you find a way to make the individual work units move faster then you should focus on how you organize your work.