Seth Norburg of Caterpillar spoke at a “lightning talk” this morning, a short-format breakout session. In his session, he talked about how they split project management duties in all projects between what they call a Project Leader, and a Project Coordinator. This is particularly interesting for teams that have both PM’s and PC’s, and are trying to figure out how to best utilize both.

In Caterpillar, they intentionally split these roles on all projects. Their logic is that, if they don’t, the Leader too often gets tied up in the project details, and the project goes off track. By engaging a Coordinator to do the “head’s down” work, the Project Leader is free to keep a “head’s up” view, ensuring the project stays on track and realizes its expected benefits.

The Project Leader / Manager is responsible for the overall success of the project, and manages the “art” side. Their responsibilities include:

• Manage project to achieve its objectives
• Acquire resources
• Accountable for project execution
• Monitor project performance KPI’s
• Identify issues and take corrective actions
• Provide technical expertise and direction, and coaching
• Business partner relationship management
• Communicate to stakeholders
• Manage conflicts and crisis

The Project Coordinator takes direction from the Project Leader, and is responsible for execution, as directed by the Leader. They are the “scientist.”  This includes:

• Following established PMO methodology and standards
• Facilitate project planning, and manage execution to the plan
• Project creation and validation
• Project analysis, management and control (critical path, risk)
• Project report generation and distribution
• Project planning updates and maintenance
• Project administrative functions, including financials

In this strategy, Coordinators are typically assigned on multiple projects.  With this approach, a clear definition of roles and responsibilities is key for success.

One of the most talked about sessions yesterday was delivered by Seth Norburg, Program Management Supervisor at Caterpillar. In his session, Seth walked through their journey introducing Agile methodologies to this 100 year old industrial giant.

Mr. Norburg’s team was a central PMO which provided something like consulting support to local teams as they structured and implemented projects.

They initially had one software team that had adopted agile, which was quite successful . When another team asked the central PMO to help them adopt agile as well, it did not go so well. In fact, the words they used were “total failure.” In reviewing the lessons learned, they determined that their failure to implement agile for the second team was because they had:

1. Insufficient knowledge of Agile methodologies
2. Didn’t know which “agile” methodology to use
3. Needed to engage more teams

The next opportunity they had to implement agile was with a team that had rampant scope issues – uncontrolled scope, frequent requirements changes, and constant planning and re-planning cycles.

What they did this time before implementing was to start by reaching out to key stakeholders to identify the team’s current understanding of and attitudes toward agile, so they could plan appropriate training and response strategies. They found that the team thought that:

• If we use agile, we no longer need to meet deadlines
• our project is too big for agile
• we are not executing an it project, so agile is not applicable
• we cannot use agile unless we’re co-located
• We don’t need a plan in agile!

Their early and consistent focus was on education and training, which included identifying key points of resistance and trying to address them.  Key to this was focusing on the things that are similar between Agile and Waterfall:

1. BOTH use iteration and progressive elaboration
2. Both have a project leader – both have a charter. The PM / lead facilitates collaboration between team and stakeholders. So, in the end, it’s all about working with people to achieve something.

And, ultimately, business sponsors don’t care what we do to deliver, they are just concerned with the results.

As they implemented, they focused on three areas:

1. Education and training
2. Change Management
3. Providing flexible service offerings to support the right methodology

But… which methodology was right?

 

The Methodology

The Caterpillar team looked at Agile methodologies, and decided that the only methodology that could manage their work at a project, program and portfolio level, and address the needs of waterfall components in a program was SAFe Agile. This approach:

• Is based on Lean/Agile principles
• Supports  Scrum, Kansan and XP
• Provides agile portfolio and program management
• Best scalability and adaptability

 

Hybrid Programs

 

Of course, it did not make sense to take all teams agile, nor could they ensure that all teams on the same program were agile – sohow to manage a hybrid program? Below is an illustration of how they combined Agile and Waterfall projects in the same project –

• They aligned user stories to hit key milestones and dependencies.
• Their general rule was that each sprint sprint had to have some kind of material deliverable, even if that didn’t go into full test
• They then superimposed management milestones
• Added GANTTs of Waterfall based work (legal, infrastructure, etc.)
• Finally, to tie it together, they maintained a detailed Dependency Log, which outlined dependencies between the Agile teams and Waterfall teams – this is KEY to making it all work

 

 

 

Waterfall Remains

They are and plan to continue running in a “hybrid” environment, because some projects are more fit for Agile, some for Waterfall. Generally, their approach was that if a project had a very hard scope, it was better for waterfall. If there was any chance or opportunity the scope would or could flex, they would drive it to agile. And they freely admitted that this choice wasn’t always easy, nor always right the first time. They found on occasion that they needed to take a Waterfall project Agile, or an Agile project Waterfall.

 

Tools

As far as tools go, it sounds like this is a work in progress. For the Waterfall components, they use Primavera – this also seems to be where they do the bulk of their financial planning, representing each agile sprint as a 2 week task-bar. There is no automated integration today – it is all manually entered – each and every sprint.

On the Agile side, they use Microsoft  Visual Studio Team Services (VSTS). This tool allows teams to enter and manage epics, features, stories and tasks, and also supports Kanban. Though other tools can provide these features,  they already had in-house expertise, so decided to go with it.

The down side of these tools is that there is no integration, so there is a lot of post-processing manual number-crunching done to get monthly actuals. Though not stated, I imagine the dependency tracking must have all been manual, and probably a lot of work to maintain and keep up to date.

Lessons Learned

• Education is absolutely key to success in implementing Agile, and it must be a top-down transformation
• Target a successful pilot
• Develop a robust model for education, addressing the needs of team members, scrum masters, product owners and agile coaches
• Transformation is not easy, and requires a total mindset change.
• Understand the benefits of when/where to use agile, waterfall or bot