#Agile versus #Agenda – #Rugby versus #Football #PMOT #JIRA #Sciforma #Favre

We were talking the other day about software products that are used to help the execution of projects in either an Agile or Traditional manner. In particular, the discussion was the difference in models used in JIRA versus Sciforma. JIRA follows the Agile or KanBan model while Sciforma follows the Traditional or Scheduled model. The difference between the two models seemed to be grounded in the concepts of whether planning is done in the temporal dimension. (i.e. have we created a preliminary schedule of when activities or tasks would be done and considered dependencies) In fact, you can’t plan in JIRA temporalily without buying add-on components like Tempo-Planner. (Which is probably where they ended up getting the name from)

Rugby versus Football

First of all, when I mention Football I am referring to the American or Canadian version of football. Sorry european and world Soccer fans.

It then became apparent how good of an analogy Rugby versus Football is for Agile versus Traditional.

There were three important observations:

      1. Agile isn’t better than Traditional and Traditional isn’t better than Agile. They are fundamentally different games. The methods and objectives are different.
      2. Although both sports have positions and specializations, Rugby players play in 100% of the game (pending injury substitutions), while Football players typically play 50% of the game. This is similar to Football where there is more specilization and subsituting of players.
      3. And perhaps the biggest difference – Rugby is a game more built on flow and reaction, where Football is built more on set plays that are planned and scheduled. (See where I am going with this?)

The point again should be that the games and objectives are different and that one game is no better than the other one.

Agile versus Agenda

My next thought was if we could find a nice, short term for Traditional like Agile that helped to convey the difference between Agile and Traditional like the analogy of Rugby and Football did.

When we look at the definition of Agile, we get:

“relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

It took me quite a while and lot of research, but I think I finally settled on Agenda. Agenda is a term I don’t believe I have heard used when discussing Sotware Development. When we look at the definition of Agenda, we get:

a list or outline of things to be considered or done

The important difference here is that an Agenda is a list with a temporal dimension. In addition, an Agenda is perceived to be an initial plan that is to be modified and added to as agreed to. In fact, the first item usually asked in all meetings that have an Agenda, is if the Agenda needs to be modified.

Perfect. Agenda Software Development. Like Agile Software Development, but with an initial planned schedule, outline, and temporal dimension.

Finally a term that conveys the accurate intent of Agile Software Development with a schedule. And that schedule is to be changed, modified, enhanced, and pivoted.

Yeah, Agenda Software Development. That’s the ticket. And in an Agenda Software Development project where Brett Favre, the gunslinger, is the Project Manager. Yea, that’s the ticket.

 

 

The Future of #AI Augmented Project Management is misguided #PMOT #Agile

robot

I haven’t read a Project Management article for a long time that spurred me to write a bog entry within 24 hours. I had that experience yesterday after reading The Augmented Project Manager by Treb Gatte. This article provided an introduction to the interesting application of Artificial Intelligence to the Project Management role.

Treb discussing the three areas of Project Management that could be affected by the application of Artificial Intelligence:

  • Planning
  • Resource Allocation
  • Tracking

Planning

Treb discuss the future of AI Augmented Project Planning:

“Imagine if your scheduling bot generates a proposed project plan, based on the aggregated and anonymized experiences of similar sized companies doing the same type of project. Today, we use tools like Monte Carlo to simulate this information. The bot could incorporate real world data, potentially yielding better results.”

Let that thought percolate while we moved onto Resource Allocation.

Resource Allocation

Treb then illustrates the possible future of Resource Allocation:

“For example, your resourcing bot determines that you need a social media expert on your project on April 5th for two days of work. It searches data sources like LinkedIn and your public cloud calendar to find a list of suitable and available candidates. Three are West Coast of the U.S., one is in Paris and one is in Sydney. It then automatically reaches out to these candidates with offers. If multiple people accept, it automatically manages the negotiation. Once complete, the planning bot is informed, a virtual desktop with requisite software is provisioned, user login credentials are generated and the specific task information is sent to them. When the job is complete and rated as satisfactory, the bot coordinates with your accounts payable system to pay the freelancer. The planning bot automatically updates the plan and pushes the data to the BI dashboards.”

I’m not sure this illustration involves much Artificial Intelligence as it really if just about integrating with existing technologies and platforms – but I digress.

Tracking

And then finally Treb discusses what the future of AI Augmented Project Tracking might look like:

“Project feedback loops on work are awful. The largest challenge is incomplete data, which results from increasingly fragmented work days, limits of the worker’s memory and tools that rely on human input. It is also incomplete as it serves little benefit to the person entering the data.

Workers are overwhelmed with tasks arriving via multiple communication channels and no consolidated view.

Imagine a world where the timesheet is antiquated. Today, we have systems such as Microsoft Delve that know what content you’ve touched. We have IP-based communication systems that know what collaborations you’ve conducted. We have machine learning capabilities that can determine what you’ve discussed and the content of the documents you’ve edited. This week, we have facial recognition capabilities and other features that can track and interpret your movements. Given all of this, why is a timesheet necessary?”

Opinion

Oh boy, where to start? It seems like most of focus of AI Augmented Project Management seems to be on the collection of data that will make the results better.

  • “If we have better historical data, we can plan better”
  • “If we have better, faster access to resources, we can complete tasks better and faster”
  • “If we have better real-time data on tasks, we can report status and adapt better”

The Problem

The problem was all of these perspectives is they seem to be promoting, advocating, and recommending less human interaction between Project Managers and their teams. If we only had AI augmented Project Management, we can go back to our closed doors and avoid the pesky human interactions. Agile Project Managers realize that human interaction is he crucible of project success – AI Augmented Project Management seems to have forgotten that.

Yes, planning is hard.

Yes, resourcing and building high-performing teams are hard.

Yes, tracking and adapting the project is difficult.

But the answer is more interaction, communication, coaching, caring, and collaboration. Not less.

I’ve even seen another article promoting that chatbots could help to get status updates from team members. Oh yeah, that will greatly improve communication of information. Developers will just love getting the impersonal 9:03 am greeting of “What are you planning to do today, what did you complete yesterday?”

Summary

I believe the idea of AI Augmented Project Management will end up on the trash heap with the CASE tools that were going to replace developers in the 80’s, Artificial Intelligence can assist augmenting individual competencies, but not replacing team communication, interaction, and problem solving. Perhaps, there is a role for Artificial Intelligence in reviewing plans and highlighting possible areas of concern regarding scheduling or estimation that a human can review. But the automated  creation of plans, resource allocation, task assignment, and task tracking is misguided.

The idea that worthy Project Manager work is stakeholder management,  but not team collaboration, engagement and communication is wrong.

Software Development is a team sport, and requires collaboration, communication, and engagement to plan, resource, and adjust. The idea that you can broadcast the skills you need and just drop a resource in to do a task and not worry about culture, fit, team dynamics, and personalities is pure hubris. These are people working on complex, nasty problems. They need time to gel, bond, and collaborate.

Sports is frequently identified as an area Artificial Intelligence has helped. Absolutely. Artificial Intelligence can refine skills like throwing a football and shooting a puck. Assisting in team dynamics and planning remains elusive. Coaches still call the plays and adjust plans. Even coaches that leverage technology realize that…

 

#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.

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. 🙂

 

 

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 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…