The #Two traits great #Managers have #PMOT #Coach

Managers and management in general usually have a bad reputation. That is probably  doubly so for middle managers. These roles are usually the first ones identified for job reduction and attrition. Why is this? Truth be told, it is an exceptionally difficult role that not many people excel at. Usually people excel at one aspect or another of the role, but not at all of the aspects.

What makes a great manager?

So what makes a great manager? The manager must be an agent for the decisions and directions that come from above AND be an advocate for the teams that ultimately execute the work. Unfortunately, most managers tend to primarily identify with either agency or advocacy, but not both. Most managers focus their effort on managing the teams, but not managing the executives. Managing-up is one of the most difficult and challenging skills and most also be welcomed by the culture of the organization.

It is a delicate balancing act that experienced managers deftly handle – the right balance of agency and advocacy that promotes high-performing teams both above and below them. If this balance is not appropriate the manager usually defaults to just concentrating on one or the other – to the detriment of both executives and teams.

But when a manager has the right balance, they build credibility with both executives and teams. Once that credibility is built, the managers are then invited in to discussion and designs to influence, contribute, coach, innovate, and inspire both executives and teams.

Two Traits

The two traits that a manager or Project Manager must have to reach this level of proficiency are Business Knowledge and Realization Knowledge.

  • The manager or Project Manager must understand the business domain, business strategy, and culture of the organization they are an agent for. Why does the Business Exist? What is the Strategic Plan? Who are their internal and external clients? Who are their competitors? What are their values and principles?
  • The manager of Project Manager must also understand the realization domain and implementation processes as well. Whether the realization practice be accounting, engineering, software development, or teaching – the manager needs to understand the work and the profession. How do we implement changes? What professional skills are required? Who are the experts and why? What are the industry-accepted best practices? What are the new methods and technologies on the horizon? What practices are no longer being used?

Only when the manager has both these traits, will they have the credibility to be invited in, contribute, coach, influence, and help to innovate the strategy of the business and the implementation of business initiatives.

This is a not an easy combination to achieve and the lack of the these traits can lead to just ‘paper-pushing’ as the manager doesn’t have the credibility or knowledge to do more. Most times a manager may have one or the other trait and while this is beneficial, true high-performing teams arise when the manager or Project Manager has both.

Our responsibilities as managers is not to just perform administrative duties, but to relentlessly inquire and learn both about the business domain and the realization domain. Only then will the manager be an integral member that makes the executive and team members better by coaching up and down.

#PMO Visual Management Tools #PMOT #Agile

I have now been the Manager of the Project Management Office at the University for Manitoba for over two years. One of the first items I struggled with was trying to determine how to visually communicate the status of the portfolio of projects in a visual, intuitive way. I was a huge proponent of visual reporting and communication from my days as an Agile consultant. A textual or tabular report of the portfolio of projects just doesn’t inform stakeholders easily as to the breadth, depth, and status of the portfolio of projects.

Epiphany

Late one day, I had a discussion with our CIO in regards to how he had seen a radar diagram used as a means to communicate the life-cycle of Infrastructure within an environment. After a short discussion, we had formulated a plan as to how it could be used to display the portfolios of our projects.

We had devised a template to show the following:

  • Separate portfolio sections with
    • Projects represented by coloured circles of different sizes
    • Status of projects indicated by circle colour
    • Projects on hold indicated by a diamond
    • New projects shown by a distinct circle icon
    • Size of project indicated by size of circle
    • Indication of a project being over budget by a halo around the circle
    • Project phase indicated by the circle’s proximity to center of the radar
    • Project’s progress indicated by the circle’s overlay to show percentage complete

Results

The Portfolio Radar diagram has been refined over the months. but it is probably the most requested document the Project Management Office produces.

Recently, I have created a personal radar that I use to track my to-do items. Like a lot of managers, I usually have 10-20 items on the go that need periodic attention. These items can usually be categorized into 3-4 “portfolios”. The radar template is much more appropriate than the standard kanban board used for projects as the items can be recurring and of extended duration. Some of them can be standing items which are never really done. The “Personal Radar” is a great diagram for showing which items need to have attention paid to them next week and which ones can wait.

Like the Portfolio Radar, the Personal Radar indicates:

  • Separate portfolio sections with
    • Items represented by stickies
    • Urgency of attention indicated by stickie colour
    • Stickie phase indicated by the Stickie’s proximity to center of the radar

This “Personal Radar” for the PMO Manager has been a great assistance to stay of top of multitude of items required in the PMO. The Personal Radar gets reviewed at the start of the week to plan the week and at the end of the week to ensure the items received the attention they deserved.

So far, this is becoming a key deliverable to stay on top of items. An example of the Personal Radar is show below:

Summary

The Portfolio Radar and Personal Radar have been excellent diagrams to use for communication of project status and task management. I’d love to hear your experiences with other means of visual methods for Project Management and personal management.

Student of the Game #PMOT #NHLJETS @srogalsky @MarkScheifele55

As I sit down to author my first Blog entry of 2019, I reviewed my recent Blogs. Although I knew I hadn’t Blogged for a while, I wasn’t aware that I had not Blogged since July 2018. I had gotten quite busy in my new role of Manager of the Project Management Office at the University of Manitoba, but I was unaware just how busy I had become. So one of my resolutions for 2019 is to create a new Blog entry every month.

In hindsight, joining the University of Manitoba was one of the best career moves I have ever made. I have grown immensely over the last 2+ years and learned so much from colleagues both within Information Services and Technology and with external units and faculties. I would highly recommend the experience working in Higher Education. The people are brilliant problem solvers and the problems are complicated and have high impact. But that isn’t the reason for this first post of 2019.

Student of the Game

I was fortunate enough to have worked with Red River College during my career and was honoured to be invited to Keynote the BTM Tech mash-up they were putting on. All I had to do was come up with a topic! I talked about options with the organizers and we discussed presenting on how projects are managed at the University of Manitoba and how the work environment is different between Private Companies, Government. Consulting, and Higher Education. I still wanted something to leave with the students in regards to habits and practices of successful team mates. I eventually landed on a Student of the Game summary at the end of the presentation. I remember talking multiple times with Steve Rogalsky on the concept of Student of the Game, We both had felt it described a set of behaviours that were inherent in all the great team mates we had worked with. Even better I was going to connect it with Mark Scheifele for a Winnipeg Jets connection. I think I had a winner!

So what do we refer to when Steve and I mentioned team mates that were “students of the game”? I came across a great article “How to become a Student of the Game” by Anthony Iannarino. In this article, Tony makes the following three excellent points:

  1. Study the Fundamentals
    • The best performers in any endeavor spend a great deal of time studying the fundamentals. They read, study, and practice the basics. The best performers are willing to spend time on the plateaus, plugging away at the basics, even when it feels like they aren’t making any real progress.
  2. Make Distinctions
    • Reading, studying, and practicing are what allow high performers to make distinctions. They start to notice things. They notice things about themselves, and they notice things about others. They start to see how tiny changes produce outsized results.
  3. Teaching and Learning
    • The highest performers seek out teachers. They know that someone who has already had the experiences and made the distinctions can help them understand their own experiences and make their own distinctions. They’re excited about the prospect of someone facilitating their learning.
    • These high performers also learn by teaching others. The very act of sharing what you have learned takes your mastery to new levels. It means you have to think deeply about the how, what, and why something works.

Mark Scheifele

I then connected the concept of “Student of the Game” with Mark Scheifele and reviewed how Mark is a great example of being a “Student of the Game”

  • Selected 7th overall in 2011 in NHL Entry draft
  • Sought out Dale Hawerchuk at 17 to seek advice and counsel
  • Added Hall of Famer and skills coach Adam Oates to his off-season workouts
  • Attended Gary Roberts Summer Hockey Boot Camps every year for 6 years
  • Never swears on the ice – Respect for the Game

Summary

I added the connection to Mark Scheifele because of the concept of having Respect for the Game. This is something Tony did not mention but I think is critical for being a Student of the Game. The presentation even allowed me to connect the “Student of the Game” concept to the Agile Principles!

  • Continuous Learning
    • Find a Mentor or Role Model
    • Get on Twitter – follow other experts and read
  • Reflection
    • Review your work and others to spot opportunities
  • Collaborate and Learn from others
    • Review others work and practices
    • We are smarter than me
  • No Ego
    • Be respectful of others and their contributions
    • Understand that there are always things to learn and get better at
  • Be Brave to be wrong
    • Help to create a safe space to experiment

All in all, I think this presentation touched all the bases and it was very well received. I encourage you to read Anthony Iannarino’s article and watch a Winnipeg Jets game. GO JETS GO!

 

Is my #PMO #Agile?

I recently presented on Agile Project Management Offices at Canheit 2018 at the lovely Simon Fraser University Campus in Burnaby. The conference was extremely well-organized and had many great sessions. The only complaint I have is that there was no bacon, but that is a small point. 🙂

In putting together my presentation, I had a to think about what makes a PMO Agile? We all know what makes a Project Agile, but how did that translate to the PMO? To further complicate the matter there are different types of PMOs. There are PMOs that deliver templates, those that dictate a methodology, those that provide a Career Centre for wayward Project Managers, and others that try to do all of these things.

I’ve always felt that an Agile Project at its heart does three things:

  1. Provides Brutal Visibility
  2. Minimizes Inventory
  3. Uses the Brutal Visibility and Minimize Inventory to deliver more value

Agile PMO

On first blush, those factors translated pretty well to an Agile PMO. But I still had to ask myself how did the Agile PMO deliver more value? I looked at Agile Projects again and how do they deliver more value? The one word that kept popping in my mind was that Agile Projects use Brutal Visibility and Minimal Inventory to Pivot or change the direction of the project. More important than that, the Brutal Visibility and Minimal Inventory allow the Pivot to be done in ‘an informed manner with limited waste’.

So ultimately I felt Agile Projects or Agile PMOs do three things:

  1. Provide Brutal Visibility
  2. Minimize Inventory
  3. Pivot in an Informed Manner with Minimal Waste

Summary

So for projects, this means Pivoting to allow the scheduling/trading/exchanging of features to deliver the most value.

For a Project Management Office, these means Pivotting to allow for the scheduling/trading/exchanging of projects to deliver the most value. And for Project Management Offices this means understanding the best way to allocate people and budget to the work required. In my expeience, budget is far easier to allocate than people with the team dynamics and role mixtures that are required on a project.

Sadly, most Project Management Offices struggle with Resource Management and manage resources in a series of Excel Spreadsheets that are usually out of date by at least a couple of months. When Project pivot decisions are required, the Project Management Office is guessing at people’s true allocation. More importantly, the Resource Management system usually doesn’t track actual hours that would indicate the leading edge of problems on projects.

To be a true Agile PMO, a Resource Management system must be used where your Resource allocation is current and the ability to Pivot exists every day. We recently implemented a Resource Management solution and the data being generated/captured is just showing how impactful it can be.

Now how many of our Project Management Offices could be considered truly Agile?

In #PID I Trust #Prince2 #PMOT

I’ve been using Prince2 as a methodology at the University of Manitoba for almost a year now and I’m quite impressed. As a methodology it is quite good and focuses on the right things. Prince2 recognizes that a project initiated well sets a project up to succeed. There three things Prince2 does during initiation that I feel set it apart from other methodologies.

Project Initiation Document – PID

The PID or the Project Initiation Document is the main initiation document in Prince2. We commonly refer to the PID as a Project Charter on steroids. The table of contents for a typical PID contains the following

  • Business Case
  • Project Definition
  • Product Based Planning
  • Project Approach
  • Project Governance and principles
  • Quality Management Strategy
  • Risk Management Strategy
  • Organizational Change Management Strategy
  • Organizational Capacity Management Strategy
  • Project Plan

As you can see from the table of contents, the PID is a much more in-depth document and agreement than the typical project charter. It also more of a strategy document than project charter by getting the project team to discuss and document strategies for Quality Management, Risk Management, Issue Management, Communication Strategy, Change Management Strategy, and Capacity Management Strategy.

There are two sections of the PID that go right to the strength of Prince2

Project Governance

One of the main strengths of Prince2 is the Project Governance and formal Project Board structure. In Prince2, the Project Boards makes all the decisions for the project and is made up of the following three roles:

  • Executive – Main sponsor or project champion – typically provides the budget
  • Senior Supplier – typically provides the resources for the projects
  • Senior User – typically will use the solution operationally when complete

These three roles are unique compared to other methodologies and it really serves the project well to ensure that all decisions are made in a balanced and thoughtful way. The really unique part of the Project Board structure is allowing for a seat at the table for the Senior User. Typically the users of the solutions don’t have a leadership role and only get involved for requirements definition and testing. By getting involved earlier, the Senior User has the ability to guide the vision of the solution. In my experience, this really allows for great value being delivered and fewer subsequent enhancement requests that are required to make the product useable. 🙂

Product Based Planning

Perhaps one of the most valuable Prince2 concepts is the Product based planning. This term refers to the Prince2 focus on what products the project is going to produce. Prince2 has a deliverable named Project Product Description. The Project Product Description is intended to describe the ultimate product that the project will produce. This deliverable helps to focus the project team to describe what project success will accomplish before defining detailed requirements. This process is very helpful and helps to create a shared vision across the project team. Prince2 then tasks the project team to define the interim product descriptions that are needed to ultimately create the Project Product Description. These Product Descriptions could be documents, demos, prototypes, or anything that is created during the project. A Product Breakdown Structure is then created to define the order the products and sub-products are created in. This Product Breakdown Structure is an excellent vehicle to uncover dependencies without having to create a detailed work breakdown structure.

By creating these three descriptions/documents, a lot of clarity is provided to the project team on what will be accomplished, what interim steps and documents are needed, and what order the project team will create them in.

Agile?

Right now, I bet you are wondering just how top-heavy and cumbersome Prince2 is. The real benefit of Prince2 is that these deliverables can be detailed separate documents or a few paragraphs in the Project Initiation Document.

Prince2 has two principles that align it with Agile:

  1. If you don’t customize Prince2 methodology then you are doing it wrong. The customization of Prince2 is one of the 8 foundational principles of Prince2
  2. Prince2 is perhaps the only Manage-by-Exception methodology I have seen. There is a section in the Project Initiation Document that defines the acceptable tolerances for the project. Only when the project goes outside these tolerances, does the Project Board need to be involved.

So Prince2 formalizes space for the project team to work and not be micro-managed.

Sounds more Agile than Scrum if you ask me…

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.