September 26, 2012 | Author: PM Hut | Filed under: Project Management Best Practices
Two Project Managers that Care
By Glenn Briskin
This week I’ve gotten inspiration from two project managers. Both are long time associates. One I’m working with now, and one is working on a project nearby. Both are making big successes out of difficult projects by expertly applying project management tools and processes. When I ask them about what’s making their projects successful, both go immediately to the processes and tools. Clarifying scope, managing change, detailed and continuously evolving estimation, managing issues and risks, team building and role definition, and communicating relentlessly form the fabric of their project management uniforms.
I’m pondering whether “the other side of risk” is at work on their projects in some way. I notice that the people on their teams and the supporting organizational units get on board and work collaboratively with their projects. Is this because of a compelling project charter or a complete and logical work breakdown structure? In part, yes. But more questions get me to a deeper understanding of their success and closer to the other side of risk.
The other side of risk philosophy asserts that:
- Application of tools is balanced with an understanding of and focus on the people involved and their individual and organizational aspirations.
The most insight on what can go right comes from visualizing perfect project outcomes in business results, organizational growth, and individual growth.
The journey taken by people on the project can contribute as much to positive project outcomes as the scope delivered.
I think that both of my friends apply these practices unconsciously or as a matter of personal values as a part of each tool or practice that they employ. As I think about their answers, the common thread seems to be that they care. They don’t apply project management as a detached overlay to the people and business undergoing the change. They bring each practice to bear because they care about their teams and their mission and the people who are depending on them.
Their teams can see that their project manager cares. He’s engaged in their mission. He asks his team members about their personal struggles. He knows why the project is important to the organization. He can talk business with the business people and technology with the technologists. He makes their success part of who he is. He isn’t there to save them by virtue of his project management prowess. He’s there to give them tools and structure and discipline that give them strength and make them more productive in getting their work done and achieving their aspirations.
That was a mouthful. Both of them care about their teams and organizations. In doing this, they naturally balance the drive and practice that comes from project management practices with finding opportunities for what can go right to help their teams and organizations grow throughout and as a result of their project. Here are a few observations on each of their projects.
One of the project managers came into the middle of his project. I got to observe his approach. He, as always, was a ball of fire rooting out and understanding problems with the project, applying better practices, and instilling confidence where confidence had waned. I was a little worried at first that his zeal for good project management practices would overshadow the underlying concerns of the people involved. They needed good project management, but they also needed someone to surface some of the organizational barriers and individual overloads that had developed. As the initial surge at renewal started to settle, some of these issues surfaced. That’s where I started to notice that my friend was moving things ahead not only because of strong project management methods, but because he was listening to people’s concerns and helping them express them and make them part of the project. For some people, it was about controlling their workloads. For others, it was getting this project, a step toward a bigger vision, back on track in a way that contributed to the vision. This project manager dug in to every issue to deeply understand it. He took steps to engage people in his projects, to express long term opportunities as well as to recognize current problems and the need to address them. He documented risks and issues. He also affirmed people’s individual and organizational needs and goals. I think his team started to see that this project wouldn’t just use them up, it could build them up. Attitudes changed, people started offering ideas about how to do things more effectively, quality of work and attention to detail improved, and people started to smile, joke, and talk about accomplishments more. Baselines were reset, management supported the new goals though the time and resources needed to complete scope increased. New efforts hit new baselines. I think that the focus shifted from what was going wrong and how cover that to what could go right and how to put that into place.
The other project manager came in early to an important project required to implement new legislation for an agency that serves citizens. The newly minted services added a burden to the agency, required new systems and practices, and were added to an already full plate. New software would be developed. This project manager is not a ball of fire. He’s a low key steady persistent breeze that fills everyone’s sails and moves them in the right direction. In his case, let’s focus on his advocacy of agile development.
Generally, agile software development is about iterative development that constantly delivers value and adjusts after each iteration to incorporate learning and new opportunities. The idea is to pick the highest value work at the start of each iteration, make a commitment, and get it done. This focuses the team on constant cooperative building of value rather than having lots of loosely connected streams of work that are infrequently connected together. Agile works very well for software development. I always advocate its use. But, agile can pose something of a dilemma to project managers.
The agile philosophy promises to deliver the most value possible within the time and cost constraints of the project. It doesn’t offer any guarantees beyond that it will always complete the most valuable work, driven by the business owner, for each iteration. Traditionally, business owners want more guarantees than this. After all, a successful project delivers the scope promised for the time and money made available. Agile seems to be saying that we will do the best we can, trust us, it will all work out.
When I ask the second project manager why his project is going well, he says it’s because of their agile approach. I ask him if he is guaranteeing his project sponsor that he will deliver everything that they want. He says no. So, I ask, how is he getting the project sponsor – a business person – to support the project’s agile approach. He says it just makes sense. The agile approach always delivers the most value possible within the time and money available. He says that the right thing to do is to focus on quality and value. After all, all project plans are aspirations we can’t guarantee because we don’t know everything up front. I’m thinking that that doesn’t seem really convincing. So, I ask, it sounds like you had to convince your sponsor and team to take this journey with you recognizing that they would encounter things that would change their course and challenge achieving their business outcomes. Right. How did you do that? Lots of conversations. What did you cover? We talked about their business and their needs and why the project was important. This let me uncover where the real value was in the project. We were able to eliminate or de-prioritize components proposed that weren’t really valuable. We came together on what new systems would help the most and did those first. So, I ask, it sounds like you understood their needs and got their trust, then they trusted you and your approach? Yeah, I guess that helped.
The second project manager’s success in implementing agile, I think, depended on his being able to show that he cared first for the business outcomes that helped its people implement the new services. The project management practices he was so passionate about were important to success, but they were built on a foundation of caring, engagement, and trust from his business and technology partners. He had understood their needs and convinced them that his idea of the right thing to do was linked to their needs.
One last much shorter story on this. My job is often to assess and evaluate other projects. I always meet with resistance to this quality oriented externally imposed project management practice. But, I manage to get past it in most cases. On one project, more so than others, the project manager had been cautious. One afternoon we had a long conversation about the importance of the project to her and her agency. It brought out a lot of new insights and opportunities for improvement. At the end of the conversation, she said to me “you really care about how we do, don’t you.” I did. After that, collaboration was natural and I think my quality assurance practices helped with their success.
Long stories short: Successful project management practices require people to engage with them. People engage with you as a project manager when you engage with their aspirations and needs. Considering the other side of risk, whether consciously applied or inherent in your style, is a fundamental part of understanding your team and your organization. It shows that you care. Caring can make all the difference.
Thanks for reading.
Copyright Glenn Briskin and “The Other Side of Risk” 2012
Glenn Briskin is a a project management consultant working with organizations around Washington State’s beautiful Puget Sound. He’s a certified Project Management Professional and has a Master’s degree in Management. He works primarily with information technology projects that improve the way state and local governments manage information and deliver services. These projects are usually complex.
No comments yet.