Can a Project Management Office be #Agile #PMOT #PMO

Can a Project Management Office be Agile? Should it? Can agilist succeed in Project Management Office?

I must admit I had thought that a Project Management Office was one of the most non-Agile entities in an enterprise. I viewed the PMO as a command and control type of structure that primarily just created templates and enforced standards. It turns out that an enlightened PMO behaves much like an Agile coach.

The first two types of PMOs do appear to be very traditionalist. Those first two types deliver limited value to the clients.

PMO Level 1

The goal of this level of PMO is typically standardization and repeatability. The vehicle for this to be achieved is usually templates and standard project deliverables. While some level of consistency is good for projects, these templates and deliverables provide most of their value to the Information Technology organization and not the client. Given that Information Technology should be a service provider to the entire enterprise, this type of PMO is a hard sell to the clients. This type of PMO is also not very Agile as the entire focus is on obedience to the templates.

PMO Level 2

Some time after the PMO Level 1 is set up and projects are still not consistent or standard, there becomes a secondary focus on the Projects Managers themselves. This type of PMO becomes a type of Career Centre to help coach the Project Managers in their career. This type of PMO is starting to recognize that projects and project managers are unique and it isn’t as easy as just defining standard templates. There needs to be more discussions and accommodation with project team members to achieve success. This type of PMO is more Agile, but still limited in the extra value it provides client. Ideally, the extra coaching of Project Managers will deliver more value to the clients, but the focus is still Information Technology.

Thankfully, the last two types of PMOs turn and focus more on the client than Information Technology.

PMO Level 3

The third type of PMO signals an important shift in focus on the PMO. As the enterprise and the PMO grows, it becomes apparent that the PMO is still not returning much value to the clients. As moe and more projects are executed in parallel it becomes harder for the enterprise to keep track of everything. At this level the enterprise requires the PMO to produce consolidated Project Reporting and then soon after Project Resourcing. Now finally the PMO is providing value to the clients by providing brutal visibility as to the status of each project and helping to prioritize the projects, people, and initiatives across the entire organization. There is never enough hours in the day, but the PMO can help by coordinating effort towards the most important activities.

Suddenly, this type of PMO is starting to appear quite Agile. Brutal Visibility and Collaborative Prioritization!

PMO Level 4

The fourth type of PMO continues that shift in focus to providing client value. Now that the PMO has provided Brutal Visibility and Collaborative Prioritization for projects within the PMO, how can that be extended outside the PMO? This is typically done by providing Governance over an idea or innovation intake process. The PMO are the stewards of the process that provides idea and innovation information to a representative committee for approval and prioritization to become projects. Usually this type of PMO is also tasked with providing additional Financial Information that will be required to determine the number of ideas or innovations that can be turned into projects.

This type of PMO finds that an annual process to reviews ideas and innovations and approve potential projects to be too slow and cumbersome. We need to meet much more frequently. Usually these Governance Committees start out meeting quarterly and soon move to monthly Iterations. (See what I did there?)

This type of PMO is becoming more and more Agile by providing Iterative Decision Making and limiting the Backlog of Work.

Finally this type of PMO reports the final outcomes of projects, both Financial and Client Value delivered. As the PMO is now accountable for the project outcomes, the PMO conducts Project Closeouts and Lessons Learned sessions for Continuous Improvement.

Summary

Brutal Visibility and Collaborative Prioritization? Iterative Decision Making and limiting the Backlog of Work? Continuous Improvement?

Can an Agilist succeed in a PMO? Sounds to me like you have to be an Agilist to succeed in a PMO. 🙂

 

 

My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.

 

Confessions of an #Agilist – Agile is dead #Pasunashi

Businessman at fork of stone pathway in water

So I’ve recently taken a job as the Manager of a Project Management Office, and I have a confession to make:

Agile is dead. I’ve seen the body.

All about perspective

When you are on the receiving end of funding, Agile makes perfect sense as it is optimizing the individual project. I give 10 projects $200K and they will deliver the best value they can individually. no problem.

But when I am on the sending end of funding, did I select the right projects? How do I decide which ones to select? If two fail, then what does that do to the company’s bottom line? Could I have used those people on more important projects? How do I justify how I selected the projects?

The Good News

The good news is certain things from how Agile lived his life has been incorporated. Iterative planning and execution is alive and well, as is User Story Mapping, and automated testing, and specification by example. A lot of the Agile practices have had a profound impact on the Software Development methods used. In some places, even Pair Programming is alive and well.

The Bad News

Sadly, the entire patient could not be saved. Now this is for a corporate environment and one that has more freedom than most corporate environments.

No Estimates is dead, Pure flow is dead, no design is dead.

Why? Predictability is king. There needs to be some business case for every project. it doesn’t have to be extremely detailed, but some analysis and design needs to be done. Some recommendation needs to exist for what the solution will look like and what the potential costs and benefits would be.

Profound

See the point isn’t about doing the project right, it is about doing the right projects. Any practice that doesn’t help us to pick the right project isn’t Agile, it is PasunashiPasunashi is Japanese for ‘Without Path’.

Selecting projects without a path and executing them without a path is not something I feel comfortable recommending.

But really Agile is not dead because once we pick the right projects, we can do them in an Agile manner and according to “Pasu ika” – Following the Path…

 

 

 

Why #Goalies make the best Project Managers and Leaders #PMOT

Penney_History

I was driving with my brother back from a family event and we started talking about the upcoming Jets and Flames hockey seasons. After some speculating on free agent signings, we started to talk about the qualities of good Project Manager and Leaders. That balance good leaders have between being persistent and committed and being able to admit a mistake and change course. There is a whole continuum of leaders that give in too quickly and some that never give in at all. What makes once person able to move on quicker than another?

We agreed that while we aren’t sure where those points are for every situation,  but we did agree on one thing. If you have been a goalie, you will find that point easier than other people. Here are the five reasons your next leader or Project Manager should be a goalie.

Goalies know they can’t win by themselves – focus on the project

No matter how good a goalie is, they can’t win games by themselves. This helps immensely to keep egos in check. They know they need forwards to score goals and defenceman to help keep goals out of their own net. More than any other position, you are brutally aware on how the entire team is needed.

In addition, your role as a Goalie is to give the rest of the team confidence as well. The rest of the team should not have to worry about bad goals in our own goal. Our team should have the freedom to challenge and rush when the opportunity arises.

Goalies know that the focus needs to be on the wins and not the goals. It is about the project and not the tasks.

Goalies know you can’t win them all – look forward

Goalies are perfectionists in their craft and in all things except having a good memory. Goalies are also extremely forgiving with their teammates and their mistakes. This provides an interesting dichotomy. I am a perfectionist until that pucks is in the net, then I need to be able to wipe the slate clean and move on. Usually there is a quick re-evaluation process and then you need to move on. This requires a short memory and a good amount of confidence.

Even more, Goalies understand that the games is made up of 20-30 mini-games and they need to be ready for the next one. You can’t get too high or too low.

Bad decisions and mistakes are part of the game. Everyone makes them so it doesn’t make sense to spend a lot of time on persecuting the guilty. Fish the puck out and move on….

Goalies know about perfect shots or deflections – don’t over plan, over analyze

You can have the perfect angle and sometimes a shot is going to beat you or is going to be deflected. That is just life and it is no ones fault. Good Goalies spend minimal time looking backward and almost all their time looking forward.

This also help Goalies to not over plan. People can over plan or over analyze because their believe it will increase the chances of success. Goalies realize that even if you spend two weeks working on something, a deflection is still likely. Rather than spending all that time planning, spend time on how you will recover because you know a deflection is going to happen.

Goalies realize communication is the key – communicate

For those of you that haven’t been on ice level, Goalies are probably the chattiest players on the ice. Always chirping our information to the defencemen – ‘time’ , ‘left’, ‘right’, ‘point’, ‘DUCK’

Goalies realize the key is rebound control – deal with issues immediately

Goalies and Project Managers and Leaders realize that issues happen. What they all realize is that it doesn’t matter how or why the issue arose, just how can we get it resolved. Having an issue is not a bad thing, booting the issue around in front of the net for 3 or 4 shots is a bad thing and will lead to a goal.

Find the issue, locate the issue, cover the damn thin up a get a whistle.

Goalies guide projects to where they want them to go – minimize risk

When I played a lot, I had a great glove hand. My brother had great lower body reflexes. So what did we do? We showed more or less to influence the shots to go to our strengths.

Similarly, a great Project Manager or leader will guide the project to where he knows the project is prepared. He or she will know the high-risk areas and compensate for those areas. I always used to hug the stick side post.

Summary

But Terry, you say, ‘I’m not a goalie, does that mean I can’t be a Project Manager?’

Not at all. But if you are a good Project Manager, it means you probably would be a good goalie. 🙂

Everything I know about Project #Risk I learned from Brett #Favre #PMOT

** FILE ** Green Bay Packers quarterback Brett Favre looks to pass the ball after falling down during the second quarter of their NFL football game in Green Bay, Wis., in this Sept. 10, 2006 file photo. Brett Favre has decided to retire from the NFL after 17 seasons. FOX Sports first reported Tuesday March 4, 2008 that the Green Bay Packers quarterback informed the team in the last few days. (AP Photo/ Morry Gash, file)

God I loved watching Brett Favre play. Sometimes.

Other times he just frustrated the heck out of me. You really had to admire the man’s commitment and desire though. He was fully bought into the team’s success. He was going to do whatever he could to ensure the team won. Even more, I got the sense that he believed that the team would win. I got the sense that he was surprised each and every time he got to the end of the games and the score on the scoreboard went against the Packers. He had all the traits you absolutely love to have in an athlete. And he had all the traits and habits you hate to have in a Project Manager.

Project Risks

I don’t think I’ve been on a project where we have managed risks well. I don’t think I’ve seen a project where risks are managed well. Everyone understands what needs to be done but for whatever reason, the risk meetings aren’t followed up on after that first risk workshop. I started to wonder again why that would be. Everyone understood the reasons behind the risk workshops and even on projects that weren’t overly busy we didn’t seem to go back and revisit risks. We even created new risk deliverables. We had risk heat maps and risk radars! And then we created them once and never really went back to review them or recreate them.

So the question is why? Why are we so bad at following up on something that most people agree is very valuable?

Just like Brett Favre, we just didn’t feel there was a lot of risk.

Be the Ball

Good project teams ‘become the project’ at some point later in the project schedule. I don’t mean they physically become the project, but they become vested the project’s vision and success. Project team member’s want the project to succeed and want the clients to realize the benefits. In this way team members become the project and lose some of their objectivity. When project team members become the project they first thing that happens is that they believe in the project, the second thing that happens is that they believe in each other. Eventually this can result in decreased formality, diminished reporting of issues and risks as the team doesn’t want to be adversarial and also they believe the issues will sort themselves out. In this way, as your project team gets stronger and becomes the project, they lose their objectivity.

Annnnnnnd before you know it you are chucking up a 70 yard bomb with 2:00 to go instead of just running out the clock.

More and more companies are now resourcing external Project Managers that are only on board for a short period of time. I believe this is trying to address the issues that can be caused by Project Managers becoming too comfortable in the client environment. Similar to the project team, this familiarity can cause issues to not be raised and decreased formality as the project managers believe more in their team mates and the clients.

Question

So the question remains. How can we reap the benefits from increased relationships to the Project Manager without losing objectivity? One way to attempt this is to use consultant Project Managers and only have them to a short period of time. I’m not sure if this is optimal though as new Project Managers have to learn the business domain and organization and just when they are up to speed they need to be swapped out. With every new Project Manager there is ramp up and learning time and with every departing Project Manager we lose valuable project and client knowledge.

Active Project Assurance

What we are implementing is a concept that has been around for a while – Project Assurance. Lately Project Assurance has taken on the form of Project Checkpoints were we get together and sing around the campfire. I jest but the weekly conference call checkpoints without everyone having the knowledge or the context of the project are not very useful.

Usually the call goes like this:

You: Got any issues?

Me: Nope.

You: OK, talk to you next week

What we are proposing here is quite different.

Active Project Assurance involves a third-party facilitating ongoing sessions with the project team to provide that objectivity while encouraging the Project Manager to continue to build relationship with the project team and clients. In our case the Project Management Office participates in the Project Initiation activities and then facilitates the Project Retrospectives and Project Risk workshops. We can then provide Project Assurance to objectively review the project while still allowing the Project Team to be the project. Without the enhanced project team and client relationships, the Project Management Office does not have biases for issues and risks. Both of those still scare the heck out of the PMO.

This allows the Project Management Office to have enough context to actually consult on the project and also allows the project teams to become more informal and build relationships that ultimately benefit the project.

And maybe we can stop the odd pick-6 while we are at it.

#Three Deadly Sins of Software Development #agile #hubris

hubris

In my experience, I have encountered three deadly sins in Software Development. Project teams can overcome almost any problems if they don’t fall victim to these three deadly sins. Unfortunately we seem to have progressed through these deadly sins throughout the years as we get more and more experienced in Software Development.

Technology-Centric

Our first deadly sin was the sin of being technology-centric. The first aspect of this was the behaviour in the 1970’s where Information Technology professionals had a belief that they knew what was best for clients and would essentially decide for the clients as to the specific type of functionality delivered. I can remember early on when we still gathered requirements from the users, but we sought no validation on the design or interface. We as professionals know best in regards to how those components should be designed. Even our terminology set the stage for the principle that the business was not informed enough to make decisions on their own. They were only ‘users’ after all. Information Technology professionals would create the system and the business could simply ‘use’ the system we created. Nothing more.

The second aspect of being technology-centric came after we begrudgingly accepted that the business were more than just users and should validate the system design and interfaces. OK, we will let you control that aspect, but Information Technology Professionals will control the selection of all the technology and patterns that lie beneath the interfaces. All of those technology choices must remain with the Information Technology professionals and it would be beyond business users to provide input on technology and patterns selected. Information Technology Professionals will decide on all architecture without collaboration.

Thankfully we now understand that if a technology or architecture is truly better, that should result in more value for the client early and often.

Methodology-Centric

Shortly after being technology-centric, we flowed right into the methodology-centric phase. Alright Mr Client, you define the requirements and value that the project will deliver, but we will define exactly how we will deliver the project. This started out by defining a very specific process for the Waterfall Software Development Methodology, but has evolved throughout the years to be equally specific and constraining processes for hybrid and Agile Methodologies.

In short, any methodology that a project follows without customization for a client, project team, or project is flawed. I’ve always thought how curious it was that Agile proponents once freed of the shackles of Waterfall were so eager to put Agile shackles on every project they saw.

Topology-Centric

And the final deadly sin is one that is a bit recent to the dance, topology-centric. I use topology-centric to refer to the desire by Information Technology project teams to be embedded at a very senior, strategic level for the project. Many times the Information Technology solution can be made better if Information Technology Professionals can work together on the business problem and not just the solution. It is ironic that early on Informational Technology was trying to limit the access the business had to Information Technology components of the project and now the business is in charge to limiting the access Information technology has to the business components of the project.

The more things change, the more they stay the same.

To be clear, the deadly sin is not to that Information Technology is denied access, but rather that Information Technology demands that they should be granted access by default.

Summary

Information Technology Professionals have to remind ourselves we are a service and need to embrace the servant leadership in all aspects of project delivery.  We as Technology Professionals only encounter these deadly sins when we think we know better than the clients. If we avoid these types of Information Technology Hubris, our projects have a much better chance of success.

Turn the Ship Around by @DavidMarquet Book Review #agile #pmot

“Turn the ship around” by David Marquet is a rare gem of a book. It is one of those books that come around once a decade. The book is very well written, provides a lot of lessons that you can apply to your situation, and is very entertaining to boot. In his story of how David Marquet turns around the Sante Fe, we can see similarities to companies, jobs, and teams in our own situations.

It is an inspiring story how one can turn the leader-follower model and turn it into the leader-leader model, even in one of the most seemingly hierarchical situations in the world, the military. I’ve read multiple books now that dispel that myth. I think the military probably gets a bad reputation of being hierarchical, but to survive has probably adapted more and quicker than perhaps any other industry.

Mistake Monitoring

There are many things that you can take away from David Marquet’s book based on what you are experiencing and what problems are foremost in your mind. For me, I was thinking about the challenge of making project reporting more lean and valuable.

So when I read the section lamenting that monitoring in the Navy was just focused on preventing errors and mistakes but not at getting better or more efficient, I immediately saw  parallels with project reporting. I was thinking the same thing about our project reporting. We report about whether the project is yellow or red and what problems we have encountered, but we rarely if ever discuss how we became more efficient or got better on the project. If we are lucky, we discuss those items in the project or iteration close outs. Many times, the items are small improvements and many times they don’t get shared outside of the project team.

It got me thinking, how can we monitor and focus on efficiency improvements on our projects? As Marquet mentioned, the bar is set quite low if success is measured by the absence of errors and mistakes. If success is just based on meeting budget and schedule, are we really trying to improve and get better?  Why wouldn’t team members just provide large estimates so that they were deemed a success. Where is the focus on continuous improvements and wanting to get better? I want to do more on my projects than just avoiding mistakes.

I don’t have answer for where this will lead and what we are going to monitor and share. But thanks to David Marquet we are asking the question to our teams and trying to determine how we can set the bar higher and get better and more efficient on our projects. Maybe that is a good place to start, to say finishing a project on time and on budget is not enough and to ask the stakeholders what other goals and objectives should this project have? And then overall, what goals and objectives should the Project Management Office have?

I’ll report back in a future blog on what we have tried and what have worked.