PMI Global Insights

Several of the experts have created graphics that illustrate areas they can help with.  I didn't want to be left out, so here's mine!   Think about making a reservation (online here) to talk to one of us or just stop by and see if there's a slot open.  

We'd love to talk to you. 

-- Dave

This post is unabashedly about adaptability and agility.

We all want to make a difference. We also want the things we work on and create through our work to make a difference. In order for the things we create to make a difference to our business clients, they have to reflect the knowledge and insights of what is needed we gain as we work on creating products. This recognizes that we can't know everything up front. 

One of the challenges with traditional approaches is how to address change to reflect the new knowledge and insights  that the business acquires along the way. We know how it works - create a change request, fill in all the necessary sections to talk about what the change means to cost, schedule, scope. risks, who needs to approve, etc. It gets even more complicated and onerous, and expensive when we are dealing with vendors. It often makes you wonder if it's even worth the effort as most changes get rejected due to their cost or schedule implications anyway. Near the end of the project the change requests are often focused on removing things from the project to stay within budgets, timelines, or both.

In my experience, some the things that get dropped under such conditions can have significant value, while some of the things that were done early on actually had far less value, as the delivery approach is not based on an incremental highest value first model.

However, when agile approaches are practiced correctly, change can be free. No really. They can be free.

How can I possibly say that?

Let's use Scrum as the premise. When teams use Scrum they do the highest value things first. The backlog has everything they know so far about what they intend to build into the product. It is a statement of intent though - it is not cast in stone. It can be changed for the next and future Sprints based on new information, changes in team and business understanding of what is possible with the product, as well as priority changes of what is highest value by the business and the Product Owner.

The Product Owner is the one that talks to the business about what the product mus do, how long it will take to build it (the number of Sprints) and the cost. It is not uncommon to fix the number of Sprints and hence the costs at the outset. A good reason for doing this is so that everyone develops a laser-focus on what is truly of highest value first. The premise for this post is this was done.

The Sprint demo is where the business gets to see what was done so far in the latest increment of the product. They also get to reflect on the choices so far about what is in the product. Their reflection is also about what to do next.

• They can continue based on the backlog grooming and hence the highest value items at the top of the backlog
• They can choose to redo the priorities of what's highest value based on what is already in the backlog
• They can choose to add new things to the backlog as highest value and hence will need to be done next

The team has a cadence to which it develops and delivers.  If you can agree on the number of total points that the product will contain based on the agreed number of Sprints, then any changes you need to make along the way, as long you drop items with the same number of points as the ones you are adding, then the actual cost of a change is free.

This is one of the ways to look at what is so paradoxically different about the thinking in agile versus traditional approaches. It forces you to really think about what matters most and to truly get the idea of being adaptable to what emerges. If something emerges that  has a higher business value than what you had previously identified then it must take precedence. 

Remember it's about what is valued most, not everything that may have value. What is valued most is based on what we currently know, which can be quite different than what we knew a month or two ago.

So whether it is an internal Scrum team, or one that as put in place through a procurement process, if you're really willing to focus on what has the highest value and willing to drop items that are of lesser value, then you should be able to make changes for free!

Jeff Sutherland, co-author of the Manifesto for Agile Software Development and the Scrum Guide first suggested the idea of change for free in a class in the Netherlands in 2006.

What do you think - can we do a better job of facilitating others to make a difference today so that our organizations benefit now and continue to do so in the long run?

If you’d like to talk strategic intent, adaptive strategy, back-casting over forecasting, outcomes over outputs, any of the agilities, or pretty much anything you think I may be able to help you with in making a difference in your world, here is my availability during the conference:

• Saturday the 28^th from 1:30 to 4:30
• Sunday the 29^th from 3:00 to 5:00
• Monday the 30^th from 9:00 to 12:00

You can also connect with me at:

• https://twitter.com/cooperlk99
• https://www.linkedin.com/in/lawrencekcooper
• www.TheAgilitySeries.com

I can’t believe it’s been a year since I had the privilege of attending PMI Global Congress 2016 in San Diego as part of the Ask the Experts cadre. I once again have been afforded the privilege of attending, this time in Chicago from October 28-30, 2017!

The Ask the Experts sessions are designed for attendees like you to have access to your peers in the profession who may have been there, done that, but also more than likely have a few scars to show for it. The point to scars is that while they may hurt at the time of the injury, you tend not to forget their lessons, well most of them anyway.

In the lead up to this year’s event I thought I’d provide a little insight for attendees for who I am (besides the scars side of it), where I came from, where I’ve been, where I’m going, and what drives me. In so doing, I’m hoping that it will resonate with a few of you who will be attending, and that’ll cause you to want to come share a bit about yourself with me. And while doing that, feel free to off-load some of your challenges with me and I’ll see if I can offer some insights that you might find helpful.

So who is Larry anyway?

I was born on a dark and stormy night in the middle of the north Atlantic (closer to reality than you may believe as my house was less than 50 feet from the ocean) on March 5, 1958, in a very small town in Newfoundland, Canada.  I graduated with a B.Sc. in Computer Science in 1977. I started university at 16 and graduated at 19 – it wasn’t because I was that smart, it’s because we only went to grade 11 back then.  Another factoid – the year I started my B.Sc., 1974, was also the year the first graduating class in Computer Science were finishing their degrees at my university! When I turned fifty, my then 5-year old looked up and said (instead of Happy Birthday) “daddy, you’re old!”  So I just saved you the trouble – I’ve been told that already.

I did my entire B.Sc. on punched cards – the PC did not come along until a couple of years after I finished my degree. What’s interesting is that in my first job with the provincial government I did everything – requirements, analysis, design (such as it was), developing, testing and deployments. Sounds a lot like the self-organizing, cross-functional teams in Scrum, doesn’t it? (if one person can be a team, but you get the idea – you had to have multiple competencies).

Starting in the late 1980’s and 1990’s and into the 2000’s I watched the IT industry turn these competencies into roles, and eventually into entire org structures – honestly I never got that, so I mostly ignored It. I was lucky enough to be in small enough size places to get away with ignoring the trend.

Along the way I also picked up an M.A in Public Administration and 20+ industry certifications on project management, Agile and ITIL. That degree is when I had to learn how to write – I was a lousy English student. Then again, I was a lousy software developer too, so lucky for me I learned how to write. So I was clearly not a NASA scientist calibre fellow like David Maynard, another of our gang of experts. But I do have talents – we all do.

We all have those moments that we feel define us in some way. Mine was a little more than a moment – more like three years to be exact.

In the early 1990’s I worked as the Operations Manager for Ice Forecasting Services at Environment Canada in Ottawa as we faced an enormous challenge.

The gist of it is that we would be replacing aircraft that flew around the Arctic and “iceberg alley” off my childhood home of Newfoundland, taking radar images of the ice floes and bergs, with a satellite that would provide full imagery for all of Canada in a single day – 7.5 GB of new data/day in an era when our largest disc drive was 424mb. That was  a lotta data!

This meant a wire-up replacement – networks, all hardware (mini computes, the workstations, etc.), and all of our software. Oh, and we had roughly three years in which to do all of it.

Some things that were pretty obvious pretty quickly:

• Doing things the way we’d always done was not going to work (e.g. taking twelve to eighteen months to build each application)
• As our existing technology was no good, we had to figure out possible options, and quickly
• As our tech was no good, and we couldn’t do what we’d always done, then we’d have to learn new skills and new ways of doing things

Necessity as they say is the mother of invention. We went to see the vendors for hardware and some of the software options that might fit. For example, we wanted four-foot wide screens to display the imagery. The response was, “you guys are about ten years too early” (we heard that a lot).

We decided to go object-oriented for any software we had to build – and none of us knew not an iota of how to code in it. We decided to assemble two small development teams that would remain intact with all the tools they needed. We set targets for having useful things delivered every three to four months. 

We decided to look at what capabilities were common across our applications and build those before we did any application development - we called them Global Services; This was 1992 and a good ten years before Service-Oriented Architecture was a thing. Eighteen months after we had made the decision, the Object Management Group came out with the CORBA Specification and called some of what we had done Common Facilities. Who knew? Once the services were built, we able to rebuild our applications at a rate one per team every 3-5 months.

And in the midst of all that, we also managed to implement automated event and incident management, as well as automated capacity management – also ten years or so before ITIL really became a thing on this side of the pond.  We had to – we only had three system administrators and over 30 servers and a dozen high-end workstations to manage that had limited capacity in a 24x7 operation.

It was the most influential three years in my professional career.

Near the end of the projects we had started, I was asked by Auerbach Publishers in NY to write a couple of chapters for the 1996 edition of their Manager’s Handbook of Local Area Networks (the book talked about almost everything but!) on the design approaches we had used (never did find out how they found me).  That was my introduction to writing beyond project documents.

I left the government after nearly eighteen years in 1995 and went over the private sector as a consultant which I have mostly done since (except for a two year stint as an employee at a telcom company 1999-2001)

My time at Ice had a tremendous influence on everything I did afterwards, especially in how I viewed the project and the software development worlds:

• Establish the big picture early and then work backwards to figure out where to start
• Never rely on the past too much to guide how you look at the future
• Set small goals
• Assemble small teams, equip them well, and provide whatever support they need to do well
• Experiment and adjust quickly
• Always deliver something of value in short increments

(My new friend David from the 2016 congress used a similar approach at NASA before we did it).

As a result of what I learned during that period, I ended up leading teams that applied the same design principles to business process as we did for software design, taking an outcomes-based approach to figure out what we needed to do based on where we wanted to go, creating an  incremental release strategy for what became the world’s largest web-enabled supply chain, and fell almost naturally into an agile way of working before the Manifesto for Agile Software Development was released in 2001 (truth be told, I never came across the Manifesto until 2009).

All of that led me to doing more writing as part of a book series I have labeled The Agility Series (www.TheAgilitySeries.com). You can read more about the series here. The newest book I am working on is called Cultural Agility: Changing our Stories . In fact I’ll be meeting one of my contributing authors to this book for the first time during the conference. Can’t wait!

Besides writing, I am a strategic portfolio executive and trainer, with a decided emphasis on organizational adaptability and agility in all its forms. I am also involved with www.NFPPC.org where we are trying to distill all of the industry frameworks, standards, and methodologies down to their essential WHATs. Why would we do that? Because so many of them overlap with one another and at times create as much confusion as they do clarity. And with all the talk about Agile it would be kind of nice to know which parts of what we already know still has value in helping us do things in a more agile way.

Why do I still work? Besides the obvious reason of having a 15-year old who won’t be leaving home for a while and then has university ahead, it’s because I genuinely like what I do. It’s fun. I have changed careers multiple times within the IT/PM profession over the years. Sometimes out of necessity. Sometimes for fun. I find the more I know, the more I realize how much I really don’t know. It’s fun learning new things and meeting new people and feeling like I am still making a difference.

The feeling of making a difference is a very human emotion. Everyone wants to make a difference and everyone does so in their own way. There also no one way to do that successfully.

If you’d like to talk strategic intent, adaptive strategy, back-casting over forecasting, outcomes over outputs, any of the agilities, or pretty much anything you think I may be able to help you with in making a difference in your world, here is my availability during the conference:

• Saturday the 28^th from 1:30 to 4:30
• Sunday the 29^th from 3:00 to 5:00
• Monday the 30^th from 9:00 to 12:00

Oh, and as much as you think we may be able to help you make a difference, I am guessing that by the end of the conference some of you will help us see things differently and change how we make a difference.

So, let’s meet up in Chicago and make a difference together!