What a Project Manager does #PMOT

I often get questioned by my kids on what exactly I do in my job. I tell my kids that I am a Project Manager and I work on teams that create web sites but that still seems to not convey ‘what’ exactly I do on a daily basis. Then last weekend I had an experience that I was able to point at to show my kids what I do at work. So what was that experience?

Building one of those metal storage sheds.

Construction

Turns out it was my wife’s idea to get a metal shed. We needed to get it to store bikes and softball gear in it. I’m usually the person to put these types of items together but this time we had a lot of things going on during the weekend so my wife got our two nephews to help. Things were going well and the floor got put together well. The shed started to take shape with the walls and frame being put together. The top frame went into place as did the middle frame that re-inforced all of the walls.

Looking back this probably was the early part of development projects where everything is going swimmingly as components haven’t been integrated and tested yet. But very soon, we were going to experience our first integration test.

Testing, Testing, 1-2-3

I hardly provided any assistance during the development, like a good Project Manager. Just let the team go. But then I was starting to hear some frustrated tones from the back yard. The last panel on the back yard wasn’t lining-up. No matter what they did, the screw holes were a centimetre apart.

They finally came in complaining about the stupid shed kit and I came out to see if I could help. I walked around and looked at the instructions and asked them to describe how they put it together and how they had tried to fix it. I checked the schematics and then they noticed that in one corner the two pieces were not flush against each other like the other three corners.

We then tried to line up the panels but the screw holes were still half a centimetre apart. sigh.

Back to the drawing board.

We then walked around the shed inside and out looking for something else that was out of line. By now we had the experience that one corner or side was probably larger than another. My nephews got the idea to measure all of the sides and sure enough one of the braces was too long. We shortened the brace and the screw hole lined up perfectly.

Summary

Over dinner that night I said to my kids that what I did on the shed was exactly what I do at work. I help project teams plan, but most importantly I help them resolve issues. Most of the time they resolve the issues themselves, I just facilitate the process.

I’m not even gonna talk about how hard the roof was to get on….

Top Project Management trend for 2014 #agile #pmot

As we enter the new year it is always interesting to reflect back on trends that we saw last year and forecast if they will continue into the new year. From both my personal experience and reading I have done, I think there be one predominant  Project Management trend we will continue to see in the new year. In particular, I believe we will see this trend increasingly on successful projects.

Without further ado…

Growth of Project Management as a competency rather than a role

The practice of a Project Manager role on a project with no other competencies will continue to decline. This should not be interpreted that Project Managers are not needed! Nothing could be further from the truth! But Project Managers who are competent Project Managers and have other project competencies will become more and more valuable. Why is this?

  • These Project Managers with other competencies can assist and deliver value in other areas of the project when there is less Project Management required. Frequently Project Managers are under-utilized at certain times on a project while coders, testers, and practitioners are over-utilized
  • These Project Managers with other competencies can manage the project much better when they understand the issues, understand the complexities in solving the issues, and understand what to get worried about and what can be ignored. Without this context of being a practitioner, a Project Manager is much less effective and can actually cause his/her team more work rather than less.
  •  These Project Managers with other competencies can build better rapport with the development team. No longer is there an ‘us’ versus ‘them’ segregation in the Project Team. As project team members also take on more Project Management competencies it becomes everyone’s responsibility to manage the project. Developers help to manage the project, Project Managers help to build stuff and the client gets more value.

But what if I don’t have other competencies?

The good news is that there is time to build up these additional competencies to help your teams deliver as much value as possible to the client. Every Project Manager I have worked with has had secondary passions to augment his/her Project Management competencies. Some love analysis, some love testing, some love client relationship building, some love learning about the business domain, and some love coding. The key is to seek out how to continue to improve those competencies and then seek out tasks on the project that you can work on. If there are no project tasks that are applicable on the current project, I encourage you to study on your own time as future projects will require these competencies. As Agile continues to grow, fewer and fewer projects will have a full-time Project Manager that has no other responsibilities and competencies.

I choose Data Modeling and Database Programming as my additional competencies.

Cross-functional teams are here to stay. Remember how awesome those multi-class Fighter/Magic-Users characters were in Dungeon and Dragons? Could a Fighter be of value to the group? Absolutely, but a multi-class characters can handle and help in many more situations. Similarly, integrating Project Managers into those cross-functional teams will deliver the most value to the clients and provide the most interesting and challenging work to all team members. It is the best way to guarantee you are always in demand.

And you just may remember why you loved coding at the start of your career. 🙂

#Agile and Music – Have we been selecting Project Managers incorrectly all along? #PMOT

I’m always fascinated by stories where other industries seem to have arrived at the same practices that have become common place in Agile.

In the final chapter of “Beautiful Teams”, there is a chapter focused on how Tony Visconti manages his projects to produce music. He has worked with David Bowie, The Moody Blues, Thin Lizzy, among others. You can check out his story on his Wikipedia page that can be found here.

Musical Planning

I was fascinated to read how Tony manages a process that is even more dynamic and creative than the Software Development process. But he did make one observation first that I believe translates to Software Development. He states that the reason artists place their faith in him is because he was/is a musician as well. For artists to place their faith in him they have to feel that he understands them and their perspective. He has to have the context to tell them they are being unreasonable at some points.

I also feel that great Project Managers should have been developers in the past for the developers to trust them during the project. A Project Manager who has limited knowledge of technology and the process of Software Development is at a great disadvantage when trying to assist Software Development teams. How can he or she understand why something is truly an issue? How can they spot a small issue that can balloon into a major risk if they don’t understand the process. They also need to have the context to tell the team or the business that they are being unreasonable.

Equally fascinating was the discussion about the two visual boards that Tony uses. He uses a derivative of a Kan Ban board so that the musicians can understand at one glance what the status of the project is. He also employs a separate board that lists the number of days left until the next milestone. (whether than be an intermediate one or the end of the project. Tony also talks about how the entire team comes up with the content of the plans. Tony seems to manage his projects in a very collaborative and Agile manner.

Here is a snapshot of his Kan Ban board derivative.

musickanban

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tony also makes many other great observations that translate  into Software Development. His discussion about how important personalities and team chemistry is fantastic. Highly recommended read.

The one Idea

But the one idea I took away from his story is that I believe we have been assigning Project Managers incorrectly all these years. Instead of having Project Managers being one of the first people assigned and then building a team around them, I feel that the team should be assembled first and the entire team should then decide on the Project Manager. Like the artists who elect to have Tony work with them, the project team is being asked to place their faith in the Project Manager. The project team needs to have 100% faith in the Project Manager – after all they are trusting him with their project.

Rather than viewing the Project Manager as managing the project and the team, the Project Manager is really just producing something for the team. I wonder how much more successful Software Development projects would be if the teams were able to select their Project Managers. The team would start out with enhanced trust of the Project Manager as they choose him or her.

Great book and excellent chapter. You can find the book on Amazon at the following link.

#Agile PMO – A new hope #PMOT

On my most recent project, I have had the good fortune to be asked to help to lead the Project Management Office. (PMO) There had been multiple leads of the PMO before, but each one was not able to provide all the information that the senior stakeholders were asking for. Given my background in Agile, I was very interested in how I could create a PMO that was lean and focused on value as much as possible.

The Project

The project is an enterprise implementation of an SAP solution. All told, there are hundreds of sub-projects that are required. At any given time, there are 20-30 sub-projects that are executing at any one time.  It is a large, nasty, wicked matrix of sub-projects, requirements, and issues. Although I had done extensive Project Management and some Program Management, this was at a scale that I had less experience with. I did have three huge advantages though:

  1. Relationships – I had excellent relationships with the other teams and Project Managers in all of the different sub-projects. I also had previous relationships with the Chief Architect and Project Director.
  2. Trust – I had built up trust with the Stakeholders for the project. We had built up a relationship over the past year where we could have honest discussions on any aspect of the project.
  3. Experience – Although I had limited experience on leading a PMO for a project of this size, I did have the experience of seeing what the previous PMOs lacked. This gave me a head start of what I felt we needed to ensure this PMO delivered. Of course, we would need to validate this with the stakeholders.

My Approach

I knew I wanted to implement an Agile PMO, but what exactly does an Agile PMO look like? I needed to do some research…

Luckily I found the a book titled “The Agile PMO” by Michael Nir. This book was an epiphany. It provided grounding and affirmation on what I felt an Agile PMO should be. The book also provided clarity in the ways that PMOs can go astray. In particular, Michael Nir described the three typical types of PMOs mistakes:

  1. Tactical PMO – The Tactical PMO is created in response to the enterprise’s need for consolidated visibility on the all the disjointed projects that are currently executing. Sadly, there is usually isn’t analysis or planning on what value the PMO should provide other than providing consolidated information.
  2. Methodology PMO – The Methodology PMO is created to provide templates and standards in the hope that everyone executing projects using these standards will result in more predictability and visibility. Closely related to the Methodology PMO, is the Tool PMO where the adoption of standard tools is seen as the solution to being able to provide more predictability and visibility.
  3. Project Manager home PMO – The Project Manager home PMO is a PMO that gets created as a Career Centre for the corporations Project Managers in the hope that using standard Project Management will provide value to the corporation.

After I read these three types of PMO mistakes, I immediately recognized all the PMOs I had seen gone astray in the past. Sadly, I think most of my own previous PMO efforts were variations of the Methodology PMO. I felt shame.

Michael Nir then succinctly described the solution – the Value PMO.

Michael’s definition of a value PMO was :

“A PMO creates value through assisting the organization decide where to invest its resources for the optimal return on investments. Tools, methodology, techniques, processes are all nice to have, however they do not constitute an objective in themselves.”

awesome. We now had a vision.

Our PMO

Now that we had a vision, it seemed clear to me that we needed to confirm our PMO vision in three areas and gain agreement from stakeholders:

1) Confirm the Objectives that the PMO would have with the Project Stakeholders

2) Confirm the Value that these Objectives would deliver with the Project Stakeholders

3) Confirm the Service that the PMO would provide to the sub-projects themselves.

For points 1 and 2, the following matrix was developed and validated as being correct for the Project Stakeholders:

Objective Value
1) Validate planning standards across the program Minimize the probability and magnitude of changes required to the amount of project work by confirming that the project scope is understood.
2) Create a program level schedule for key development, testing, and implementation milestones – at the project and feature level Allow Stakeholder visibility on the plan so that we can ensure people are working the most important items. Also allows for Stakeholders to have a line-of-sight so that decisions can be made if the schedule is not acceptable. These decisions can be priority calls, people assignment, or scope inclusion/exclusion.
3) Assist projects in getting assistance with issues Help to resolve project issues asap and minimize the effect these issues have on the project and program
4) Assist projects in creating and executing mitigation plans for identified project risks Reduces the project risks and the effect these risks will have on the project and program
5) Provide consolidated reporting Allow Stakeholder visibility on the execution so that we can ensure people are working the most important items. Also allows for Stakeholders to have a line-of-sight so that decisions can be made if the schedule is not acceptable. These decisions can be priority calls, people assignment, or scope inclusion/exclusion.
6) Provide guidance on enterprise standards for project deliverables Provide consistency across projects to minimize the probability and magnitude of changes required to the amount of project work by confirming that the project scope is understood.
7) Validate Resource Plan across the program Minimize the risk of resourcing issues in the future by validating that adequate resources are allocated and that the resource plan is realistic and reasonable

For point 3, we perhaps set the PMO tone in the most important way. Instead of the PMO telling the project what they needed to do,  our focus was on asking projects how we could help them. For example, we asked:

1. Are there any obstacles we can help to remove?
2. Do you need any additional people, resources, or changes in priority  to keep to the plan?

The story so far

We have received extremely positive feedback on this new Agile PMO. I’ll create a subsequent post on how the PMO evolves as we work with the Stakeholders, but indications are that this PMO is positioned very well to succeed and provide true value to the corporation.

Mostly importantly the Project Stakeholders AND the sub-projects see value it what we are doing…

What dance do you do when your project is Yellow? #PMOT

It seems that everyone is pretty comfortable when it comes to the definition of a project that is either green and red.

Green – everything is going well, on track for schedule, scope, and budget.

Red – serious problems that need stakeholder help to resolve. Probably unable to materially meet schedule, scope, and/or budget.

But Yellow?

Yellow seems to be the colour in the middle where there is a wide range of status and actions.

To some, any amount over budget turns the project yellow. Some only turn it yellow after the schedule, scope, or budget overages exceed 5%.

To some, a yellow project requires an action plan. Some turn it yellow to indicate that it is being watched, but that no actions are required.

Which is correct?

I would suggest that depends on the culture of the project, team, and client. But I do tend to see two types of yellow dances that occur on projects.

The Yellow Dances

Using using the dance metaphor, I am proposing that the two partners in the dance are the project and the project status. The dance that they do reflect the interactions that occur during the lifetime of the project.

The Green Waltz – I use the Green Waltz dance to refer to the more formal behaviour of the project and project status. In this dance, the project and project status relationship is quite formal. The status is usually communicated via status reports. Much of the focus of the project is to do whatever it takes to turn the yellow project back into green as quickly as possible. As a result, this dance is very quick as the change request tempo can become very up tempo. During the course of the dance, the yellow/green transitions(change requests) can come at a furious pace.

Pros – Any exceptions to the plan are highlighted.

Cons – The project may be green at the end and people may think it is fine, but there may have been numerous change requests that only give the appearance of everything being fine. The status does not represent the holistic status, only the current point in time status of current plan against current actuals.

The Yellow Tango – Unlike the Green Waltz, the Yellow Tango is less about seeking to become green and more about understanding the rhythm of your partner and reacting. The Yellow Tango embraces yellow and does not try to guide it back to green. The dance understands that both partners lead the dance at certain times, and tries not to force it back to green without good reason. The Yellow Tango is a slower dance, without the up tempo of numerous change requests. But if a change request is required it usually is a larger, sudden movement and change in the dance.

Pros – the status holistically communicates the status of the entire project, not just at that point in time.

Cons – The reduced formality can result in delayed escalation of issues until they become large enough. This may be an issue depending on the dance hall you are in. 🙂 Some dances halls are ok with these exaggerated movements, some not so much.

Summary

Both dances are appropriate and neither are right or wrong. Many times, the dance will be stipulated by the client/dance hall.

My personal preference is for the Yellow Tango as I feel it does communicate the overall status as opposed to just a point in time. As with the Tango though, it is a more involved and complex dance. I think it does required a more educated client and team. I also find the  Yellow Tango better for Agile projects when things are just bigger or more complex without added scope. The Yellow Tango more honestly recognizes that we don’t know everything up front and we will manage the items together in clear, open, and honest communication.

Giving #Agile a bad name

Sometimes I read articles that I feel give Agile a bad name and hurt the cause. Recently an article was retweeted from earlier this year that compared Project Management to a disease.

You can read the article here.

I’m not sure why some agilists feel a need to diminish and criticize Project Management so completely. Project Management is a valuable addition to all projects when it is done right. Unfortunately, we have all been on projects when it wasn’t done right. The article goes on to propose how Agile is the cure to the disease of Project Management:

“Happily, there is a cure. It is a program of recovery called Agile, but because the nature of the program is a complete reassessment of one’s life and career, few are able to engage, seeking, as always a quick-fix solution. Those that do embark on the Agile program of recovery are challenged by its radical notions of release, rather than control, self-organization, rather than command and management, and trust rather than suspicion. Sufferers are asked to embrace failure—anathema to the Project Management mindset. The recovery process is slow, and many, getting frustrated along the way, will revert to old behaviors. Recovered Project Managers—who come to be known as Agilsts—have great patience for their fellow sufferer and will always be there to support and guide them through these relapses.”

First off, I’m not sure Agile causes you to re-evaluate you life. But hey, maybe that is just me. 🙂

Of course this example takes the worst stereotypical characteristics of a command and control Project Manager. Would any of us want that Project Manager on any of our teams? Of course not. But I have worked with many awesome Project Managers who were not controlling and suspicious on previous waterfall projects. We can describe any role on a project in the worst stereotypical way, but it is the extreme example of naiveté to believe a process or methodology would alone be the cure.

The Truth

Are there people with bad leadership, teamwork, and management skills in Project Management roles? Absolutely. There are also people with bad leadership and teamwork skills in developer roles as well. I know you may find it hard to believe but some of them are actually on Agile projects. It isn’t all sunshine and roses on Agile projects. People have their own agendas and motivations that can hurt providing value for the client.

Agile provides the ability to expose those people and bad leadership and teamwork characteristics sooner than later, but Agile alone isn’t the solution. A person with bad leadership will likely exhibit that bad leadership in whatever methodology the project is executing under. Even in an Agile project, the person still needs to want to trust and delegate. Some people find the transition harder than others.

What is the solution? Good people with good hearts who care about each other and the project. No matter what methodology you are using, if you have good people with good hearts they will have the right balance on the project. If anything, Agile just shows the people with good hearts sooner.

Guess what? Those good people with good hearts have been successful on teams for decades before ‘Agile’ came along. These people are still successful on waterfall project today. Could they be more successful using Agile? I would say yes, but that doesn’t mean they would not be successful without it.

Summary

I myself have joked about how I have recovered to be an Agile Project Manager, but some of the best Project Managers I have ever worked with were always operating in an Agile manner. In fact, probably some the first Agilists were Project Managers who were trying to find better ways.

#Project Steward

I’ve written posts before in regards to how I dislike the term Project Manager. I feel the definition implies that the Project Manager is above the team and that the Project Manager controls or moves the resources on the project as he or she sees fit. It has the connotation of a command and control structure.

The Project Manager term does not convey that the Project Manager is there to serve the project and project team members. Rather, it is the team and team members that traditionally are viewed to serve the Project Manager.

For these reasons, I prefer the term Project Steward.

Here is the definition of Steward from Wikipedia:

Steward Definition

“Stewardship is an ethic that embodies responsible planning and management of resources. The concept of stewardship has been applied in diverse realms, including with respect to environment, economics, health, property, information, and religion, and is linked to the concept of sustainability.”

History of the term

Historically, stewardship referred to the occupation of a steward. Initially, stewardship was the responsibility given to household servants to bring food and drinks to a castle dining hall. The term was then expanded to indicate a household employee’s responsibility for managing household or domestic affairs. Stewardship later became the responsibility for taking care of passengers’ domestic needs on a ship, train and airplane, or managing the service provided to diners in a restaurant. The term continues to be used in these specific ways, but it is also used in a more general way to refer to a responsibility to take care of something belonging to someone else.

Three Reasons why I prefer the Steward term

1) It places the focus on the fact that the Steward serves and provides service to others. The Project Steward serves at the discretion of the team. In a traditional structure, that structure seems to be reversed.

2) Steward accurately reflects the fact that the Project Steward is taking care of the client’s project for them. It is clear that it is not my project, I am merely caring for it temporarily.

3) Food. Good Project Stewards understand the power random acts of food can have on team morale and productivity. It is no co-incidence that food is a focal point for stewards throughout history.

 Lastly

The definition mentioned that Stewardship is also linked tightly to the concept of sustainability. This has always been important for me as I work on projects. As a Project Steward I feel it is my responsibility to take care of the project that was entrusted to me and that I am obligated to return the project in the same or better shape than I received it. My duty is not just to complete the project or to meet the budget, but to deliver it back to the clients in better shape than I received it.

If I have done my job as a Project Steward, the clients have more value at the end then they had at the start.