How to hire a Chief #Innovation Officer #FTW

Innovation

Innovation. We want to innovate. Everyone tells us we need to innovate. Everyone else is innovating and we need to keep up to them. If we don’t innovate we will be left behind. To this end, many companies are hiring Innovation Officers, Innovation Directors, or God forbid a Chief Innovation Officer. Some companies include Innovation in their name hoping to imply they are innovative just by having that name. Governments are adding Innovation to a Ministers Portfolio name in the hopes that they may generate Innovation. Even in my own city, Winnipeg, they hired a Chief Innovation Officer and are trying to innovate.

Problem

So what is the problem? Surely it is a laudable goal to innovate, improve, and excel? Absolutely it is. The unfortunate fact is that the way people are addressing innovation has very little chance for success.

Why

Innovation processes can’t simply be overlaid on a corporate structure that wasn’t innovative in the past and Innovation will occur. In the case of the City of Winnipeg, a call went out for people to submit their ideas and those ideas would be reviewed by the Chief Innovation Officer, the Chef Administration Officer, Chief Corporate Services Officer and Chief Transportation and Utilities Officer.

Oh boy, where do I start on this one? Lets use bullet points:

• The people at the highest level are talented individuals but probably are not aware of Innovations required throughout the corporation. They are going to miss a ton of great ideas.
• What is the Strategy that Innovation is required to address? What are the objectives? A general call for Innovation will probably generate a lot of wasted time as Innovations are submitted that aren’t a priority and people will wonder why their submissions weren’t chosen. (Unless a meeting is held to do a retrospective on every submission, but my experience is that doesn’t happen in these Innovation Beauty Contests)
• If the Culture of the corporation was not open to ideas in the past, people may be hesitant to submit ideas formally via email. Some ideas may highlight inefficient processes that could implicate co-workers. So people are likely to just not respond. (especially if they would implicate supervisors and managers who hold power over them)

How to Innovate

So how would I create an Innovation Culture?

1. Just that. Realize that it isn’t about generating Innovations in your current corporate structure. Innovation is about a change project to change culture profoundly.
2. Invite people from across the corporation to participate in the Strategy Creation. If that isn’t feasible, at least communicate the Strategy in a meaningful way after it is decided. (i.e. a face to face meetings and not just sending a Strategy document out for people to read)
3. Engage the people who are interested in face to face Innovation meetings where groups can submit, discuss, and shape Innovation ideas with their co-workers. These sessions need representation from front-line staff, supervisors, managers, and executives.
4. Ongoing efforts to create a culture that is a safe culture for new ideas and suggestions. This is important. You can’t have Innovation if you don’t have a culture of Safety. You can’t have an open door for Innovation and a closed-door for everything else.

This would be a start, but it isn’t guarantee. It takes hard work and lots of communication between people and time. But there is no shortcut to Innovation.

Especially hiring a Chief Innovation Officer.

 

 

Advertisement

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?

You just have to work #here #HigherEducation

Here? Specifically? Well kinda.

But I’ve always said that it is best for an individual to have a breadth of work experience. In the past I have mentioned that I felt it was important for a person to have experience in a private company, a government agency, and a consulting company for a least a couple of years each. Each one of these models operate very differently and distinctly. And the interesting things is that no one model is better than any others. Each model has different drivers and priorities that drive their behaviours.

University

I’ve now found a found category to add to the list – University. University is a bit of a mix between Private, Consulting, and Government, but it also has characteristics present in none of them.

University does have the drive to improve and innovate from Private, the challenges of people coaching and change management from Government, and the lack of direct authority in a Consulting environment where you need to rely on the your skills as a facilitator, negotiator, and influencer.

But at University you need to do three models all at the same time and realize two additional truths:

1. Every Faculty and Department are/can be a company on its own. There are limits to any authority over them so the focus really need to be on bridge-building and selling the benefits of your ideas.
2. University culture is about questioning. But rather than questioning to show their own knowledge, questioning at University are done to make the idea better. While this can be frustrating, once you realize the questions are following the method of Socratic Questioning,  they are easier to accommodate.

Oh yeah, and with the need to facilitate and influence and answer people’s Socratic Questions, things just take longer….

But the solutions and ideas are really better.

 

First deadly sin of #Agile

I’ve always thought that for all that Agile got right, it almost got the same amount wrong. And most of what it got wrong had to do how it distanced the client from the project team.

Surprised?

Remember that although Agile was promoting co-located teams, the clients certainly had a different status than the other members of the project team. I’m still amazed that the Scrum segregation of clients and team members into chickens and pigs is tolerated. The basic premise is that although the clients are interested in ‘breakfast’ they aren’t as committed as the ‘pigs’. This of course is ridiculous and in many projects the clients have more on the line than the development team. But the most disappointing thing is that Agile seemed to inherently promote a hierarchy. Even outside of Scrum, Agile still seemed to confuse who defines value and the project team typically over steps their bounds and decide for the client. For example, the No Estimates movement deems Estimates a waste repeatedly although the only people who can determine what is waste are the clients.

Semantics

Much of this can be tied up in Semantics. The terms of Client, Customer, Business User – all separate.

It wasn’t until we were talking terminology in a more traditional project structure that we decided there was a much more appropriate term:

Colleague – ‘A person with whom one works in a profession or business.’

Or even better, from the Latin collega or ‘partner in office’. Finally a term that does not imply a hierarchy and instills the promise of a partnership working toward a common goal.  All colleagues working to create the highest quality solution to a problem.

Colleagues delivering frequently to minimize Inventory and shorten Feedback Loops.

Now that is Agile.

 

Death of #Agile #PMOT

OK, so maybe Agile isn’t dead yet. But I think it is certainly starting to suffer from the same disease that ultimately claimed Waterfall and other methodologies. As usual, Steve Jobs saw the issues years ago:

Content over process

Process over Content

Once the focus is on process over content, the patient starts to decline. Process is supposed to improve content by providing guidance and predictability. But if the process is followed blindly and no autonomy is given to team members to customize process, we have placed Process over Content. This happened late in the Waterfall days with additional focus on CMMI ranking and achieving other process certifications.

Most troubling is a lot of the discussion is the Agile world lately is about process and not content. We are talking about who is more Agile than whom. We are talking about absolutes as to how estimating is bad and that estimates should NEVER be done. We are talking about absolutes rather than compromises. You are ignoring Content when discussions gravitate toward absolutes. Is it a key indicator that you are no longer evaluating what needs to be accomplished or what value is. The discussion now is darn it, come hell of high water, we will be doing User Stories, with relative estimating, or not estimating at all. And it doesn’t matter what the clients think or what success is.

I know this because people are writing books about absolutes and not about how to compromise.

But Terry, we do listen to our clients you’ll say. We wouldn’t be doing our professional duty if we didn’t promote our preferred approach. We then customize after.

Fair enough. But your preferred approach is all about process and not content. Process enables content, but process is not content. Your focus is on the process….

I’ll let that sink in…

 

#1 difference working at the University of Manitoba #books

I’ve worked at a number of different enterprises throughout my career. I’ve seen even more of them when I was a consultant. In one way or another I have seen all the following organizations in action:

• Manitoba Hydro
• Great West Life
• Investors Group
• Multiple departments in the Province of Manitoba
• Assante Asset Management
• Manitoba Blue Cross
• Manitoba Public Insurance
• I could go on…

What is the most interesting to me is how the University of Manitoba differs from all of these in one important way. I imagine that this observation can be applied to other educational institutions as well.

I see books everywhere.

Books

What I’ve noticed is that almost everyone reads books specific to their career. Beyond that, there is a commitment to education. I guess this should not be surprising since this is a University, but the focus is profoundly different from anything I’ve seen in the private sector. Now before you jump to conclusions, I’m not saying the education budgets are larger. I don’t get that sense. But almost every project that delivers has a focus on education and training. There is just a profound focus that we need to educate people and train them and we should not expect people to just pick up new skills without training and effort.

Hand in hand with this focus on education and training comes an increased focus on innovation and improvement. Perhaps because our main clients are students who learn, we are eager to share information and learn ourselves. This gets magnified as Universities are very collaborative and we are eager to share information and innovations. This creates a larger eco-system of innovation with the goal to improve the educational system and our support of higher learning.

Since private companies are in competition, you rarely see professionals between companies sharing new methods and procedures that could help others in the industry. As a result, innovations have to be ‘discovered’ multiple times in private industries.

System Thinking

Which brings us back to System Thinking. I remember reading a book on System Thinking that proposed IT systems are designed within the larger enterprise context and can’t help but mimic the overall company culture and values. An open company’s IT systems will have less formal procedures that a company that is very hierarchical. The IT systems reflect the company.

So I guess it should not be surprising that our systems and our IT organization and culture have been modeled after the University as a whole.

 

 

A year at University #UManitoba

I have now been employed at the University of Manitoba for over a year now. I’m not sure I knew exactly what I thought it would be like working at a University, but I thought it would be good to reflect on what I have learned over the past year

The first thing that has occurred to me as I look back is that I have never, ever been more proud of where I work. The ability to contribute in some small way to the advancement of education, research, and advancement of the students at the University of Manitoba is truly inspiring. I have always been proud of where I have worked in the past, but most of the time the outcomes assisted large private companies. I just find that isn’t nearly as rewarding as ultimately playing a small part in the educational system.

The University is an environment where ideas are fostered and critical thinking is encouraged. This environment promotes collaboration perhaps more than any other place I have been in. But the University somehow continues to foster collaboration within a structured environment. This should not be minimized, in my experience the introduction of structure usually caused the reduction of collaboration. This is not the case, if anything the structure at the University of Manitoba encourages collaboration and the fostering of ideas. An important factor that contributes to this culture of collaboration is the concept of peer review. Although peer review is commonplace in the research areas, I’ve never been in a work culture where it manifests itself in the entire organization. People actively seek out each others opinion and truly expect feedback and critical review of their ideas that can help to make the ideas better. This ends up making all the ideas the best they can be and helps to make the collaboration enjoyable and without conflict.

That isn’t to say, there aren’t challenges. But a lot of the challenges come from just how large and diverse an organization the university is. Once an issue to identified, the perspective is just focused on what is the best solution is to the issue at hand.

Ultimately, the University of Manitoba is a community and has a culture all its own. I’ve worked in other placing that tried to define their culture and community. I realize now that to have a community and culture you need to have a diverse group of citizens that are all committed to the ultimate goal. For the University of Manitoba, that is education. I also realized that you define culture by thousands if not millions of small, meaningful, thoughtful acts. It is something you can’t create.

I’ve appreciated that the culture of University of Manitoba is defined by millions of meaningful, thoughtful, insightful, professional, and intelligent ideas – repeated.

Oh, and I love working on a campus with historic buildings, green spaces, and co-workers of the same mind…

And geese…. I love the geese…

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.