Why Project Managers Like Documentation
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Monday, 1 December 2008 12:39
Reposted from Artem’s Agile Software Development Blog
Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.
Fixed Constraints and Up Front Design
Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.
In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.
Project Managers Want to Succeed
Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don’t want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.
So… what can a project manager do to ensure success? Focus on paperwork and process.
Paperwork and Process Defines Success
Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.
Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.
We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.
Changing Behavior Will Take Time
If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.
Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.
I understand it is difficult to run an uncertain business. We can’t wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.
Holding Project Managers Accountable
Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.
Unless we want mountains of documentation no one will ever read, let’s stop holding project managers accountable for plans that should never have been laid in the first place.
Photo Credit: www.polaricecapz.com/
More Talking to Project Managers
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Monday, 17 November 2008 12:05
Here is my last post for Artem’s Agile Software Development… republished here for the benefit of my Leading Agile readers.
Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.
If you are interested in catching up with the conversation, go back and take a look at my post “How to Talk to Project Managers” at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man…
This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.
Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.
My talk generally followed the outline from “How to talk to Project Managers”. People were taking notes and seemed engaged… but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.
I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.
We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.
What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.
Here is some thinking I’ve done on these topics over the past year:
http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html
Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.
Learn MoreThe Agile Project Plan
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Wednesday, 29 October 2008 02:52
When we think about a project plan, what do we typically think about? Most people I talk with think a project plan is the schedule…. they think about the Gantt chart… the dependencies… and the critical path. The project plan can contain the schedule, but it is bigger than that. A project plan is a project manager’s strategy for how the project is going to be run. It is a tailoring of the project management framework and describes what processes are going to be applied to run the project.
Business Case and Charter
My approach to writing project management plans is certainly not unique, but I am also not sure it is 100% standard. A good project management plan should start off with the business case and charter. This is a statement of the value we expect from the project and your authorization to move the project forward. These documents set context for the product vision and development activities. They establishe the project constraints, known risks, and any assumptions the business is making that could have an impact.
The Product Vision
The vision should describe the customers of the product and the value they will derive from using it. It might address the market segments you are going after and any business constraints the project is operating under. There can be quite a bit of overlap between this document, the business case, and the charter depending on how your team uses these artifacts. I like to think of the vision as the place we really get specific about the product and what it needs to actually do.
You can think of the vision as describing the actors or personas that will use the system, the major product themes, and major epics that are going to be delivered to market. I might also consider delivering a high level release plan to communicate the overall project schedule.
A Note on Documentation
When talking to an agile audience, I always try to be careful to state that these documents do not have to be 100 page monsters. If you are working with a small team and with an embedded and empowered product owner, these documents can live on a whiteboard or a wiki. If you are running a large, and possibly distributed program, you may want to leverage a wiki or some other lightweight electronic communication tool. If you are working in a traditional document driven organization, you might have to create something in document form. Just keep it as lightweight as possible.
The PM Knowledge Areas
Now comes where we describe how we are going to deliver to the expectations of the business. We need to state how we are going to manage cost, time, and scope and explain how our project will manage risk. We need to let the business know our strategy for communicating progress and how will we will ensure quality. We need to communicate what we are going to do if we need to buy anything or hire anybody into the team. We need to get on the same page about how we are going to make staffing decisions and how we will handle any HR issues along the way. We need to communicate how we are going to make sure everything is working together to deliver value.
These are not questions only for traditional teams, agile teams have to answer them too. Often, we assume these things because agile processes have the answers built in. It is just part of the process. Sometimes we need to be willing to explicitly communicate how we are going to proceed in language that the business understands. A lightweight project plan can be just such a tool.
It’s all about communication
Sure… the plan might change… we want to preserve the ability to inspect and adapt. That is why we keep the artifact as lightweight as possible. The act of writing this stuff down makes sure that we think it all through, that we don’t take anything for granted, that everyone has a common understanding of how we are going to approach the project.
I have had great success in the past walking my PMO through each of the PMI knowledge areas and documenting how our agile techniques are going to manage time, cost, scope, risk, quality, procurement, human resources, communication, and integration management. The point of the exercise is not about the document, it is about getting everyone on the same page, it is about communication and understanding.
After all… that should always be the point of documentation… communication and understanding.
Learn MoreScream Free Project Management
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Monday, 20 October 2008 09:28
So here is another post I originally did for Artem’s Agile Software Development blog. This is one of my attempts to blend a non-agile topic (parenting) with agile thinking and project management. Hope you enjoy it.
Scream Free Project Management
A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.
The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying “I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm”.
How about with our teams? We desire a certain outcome on the project, we might not be getting it, so we start to get anxious. We might not scream at our team but we do exert pressure, we threaten, we manipulate, and we control. When we behave this way as managers, we are in effect screaming at the team to change their behavior so we can be at peace.
The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70′s… “The more you tighten our grip Tarkin, the more star systems will slip through your fingers”. The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.
Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.
As project managers we need to get ourselves under control first. We need to operate from a position of confidence and strength. It is up to us to lay out the vision and lead the team. We can establish boundaries and set guidelines for behavior. As project managers we monitor the system, give support, and ensure accountability.
At the end of the day… an empowered, self-directed team will deliver more than one that is being heavily managed. It is this kind of team that will help us meet our goals and deliver on the objectives of the organization. Our anxiety is all that is standing in our way… it the only thing stopping us from creating the kinds of teams that are really going to deliver. The challenge is that we have to get ourselves under control first!
Projects come in all shapes and sizes. Some are software… some are community organizations… and some projects live in your house and eat all your food. Focus on creating context… focus on managing the environment… focus less on managing people and controlling outcomes and you’ve got a much better shot at making things happen.
You’ll lead a richer life and have more fun along the way.
Here is a link to the original post on ASD: http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/scream-free-project-management
Learn MoreRefactor Your PMP: Human Resource Management
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Wednesday, 20 August 2008 01:36
Back so soon? I told you guys it was time to get this knocked out! Last post we talked about Quality Management, this post we are going to hit Human Resource Management.
According to PMI, Human Resource Management includes the processes that manage and organize the project team. Pretty simple huh? This is an interesting topic because we generally want agile teams to be self-managing and self-organizing. Do we throw this one out all together? Is there any way we’ll be able to bridge the gap?
I’ve got to honest with you guys, I am not exactly sure where this one is going to end up. Let’s jump in and see what we can do.
Human Resource Planning
PMI Definition: Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan
Does a RACI diagram have any place on an agile team?
Agile tends to assume that you are staffing your team with specializing generalists. What is a specializing generalist you ask? These are people that may have specialization in a given area but are willing and able to operate outside their area of specialization.
Specialization is problematic because it leads to matrixed organizations. If a specialized skill set is required only part of the time, we need to find something else for that person to do with their downtime. Organizations end up filling that downtime with other project work. The problem here is that working on more than one project dilutes focus and creates artificial dependencies between projects. Real dependencies are one thing, self imposed dependencies are quite another.
Specializing generalists allow me to have a single person do more than one kind of work, eliminating constraints, and reducing the need to matrix people across multiple projects.
Teams work best when they stay together and are all focused on a common objective. They establish a stable throughput, they trust each other, they understand how to work together. Agile values continuity and it’s part of what keeps agile teams fast and lightweight. This is a very difficult, if not impossible, to achieve in a matrixed organization.
That said, we still need to know overall what skills are required. We need to do the necessary due diligence to make sure that our team collectively has the competencies required to deliver. We need people that can potentially fill several roles on the team. If a RACI diagram helps you figure that out… go for it.
Acquire the Project Team
PMI Definition: Obtaining the human resources needed to complete the project
After giving this one some thought, I don’t think agile has much to say here or much overlap with PMI. I’ll just take this opportunity to restate the importance of building teams with specializing generalists. Getting the right people on the bus makes all the difference.
Develop the Project Team
PMI Definition: Improving the competencies and interaction of team members to enhance project performance
Agile teams improve competency through collaboration and teamwork.
How does collaboration and teamwork come into play on agile teams? Most teams will have a mix of senior people and junior people, people who are better in one are of the application than in another area of the application. Agile encourages close collaboration amongst team members, pair programming, and shared ownership. It gives everyone the opportunity to broaden their skillsets, learn new technologies, and become proficient in areas of the application they might not otherwise touch.
Daily standup meetings keep people involved and connected with each other. Retrospectives help the team learn from each other and decide how to work together more effectively. Creating this collaborative learning environment is one of the reasons that collocation is such an important aspect of building agile teams. Agile leaders value team building and collaboration so much, they tend to focus more energy on activities that give opportunity to develop closer interpersonal relationships.
If your team members lack a particular competency, and no one on the team has that skill, training one or more folks becomes a critical success factor. Make sure you have that time and money in your overall project plan for formal training.
Manage the Project Team
PMI Definition: Tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance.
Ideally we want our teams to be self-managing and self-organizing. Give people the objective and get them the environment and the tools they need to deliver. The agile project manager can play a huge role in creating the kind of environment for this kind of behavior to emerge.
An agile PM needs to lay out the vision, make sure the team has the necessary skills to do the job, layout the initial planning structure, establish the metrics, and support the team by removing the things that get in their way. Part of establishing structure is keeping things visible and maintaining a culture of accountability. Iteration planning, daily stand-ups, product demos, and retrospectives help create this culture.
As an agile PM, I almost always track project burndown, iteration burndown, defect trends, and historical velocity. These metrics, in conjunction with the daily standup, usually give me a pretty good idea of how the team is doing. There have been times when I have needed to track individual hours and individual velocity but these cases should be the exception to the rule.
Agile definitely puts more emphasis on leading the team over managing the team. The reality is that sometimes your team is not healthy and mature or in a good place to manage themselves. A good manager, with a focus on servant leadership, can help create an environment where teams can thrive and people can learn what it means to take full ownership of project outcomes.
Now if we could just get PMI to stop calling our team members Human Resources!
Learn More