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…