Migration to cloud is a marathon, not a sprint. Here’s why and how to get started

When cloud computing went mainstream a decade ago, early adopters quickly realized business value by migrating “easy” workloads to cloud and adopting a cloud-first strategy for new systems. Fast forward to today, when the top IT priority is to modernize existing, mission-critical applications on hybrid cloud for better business agility and faster access to data insights. To fuel that effort, cloud spending is growing at six times the rate of overall IT spending.

Yet, surprisingly, only about 20% of enterprise workloads have migrated to the cloud so far. What is slowing down the remaining 80% of workload migration? What are the obstacles on the migration path? And what steps can organizations take to realize the agility, innovation and digital transformation that is only possible on the cloud?

Why migration to cloud is a multi-year journey

Let’s look at some of the major obstacles to enterprise cloud migration.

  • Organizations often encounter unexpected and discouraging costs and complexity, even during routine lift and shift migrations.
  • Developing new apps across multiple vendors and clouds, each with their own propriety tools and management systems, has led to challenges in terms of security, compliance and governance.
  • The larger the organization, the older the application suite. According to IDC[1] 47% of existing applications in Canada are more than five years old, which means they were probably not built with containers or microservices in mind. Migrating these legacy applications can be painstakingly slow because they first must be evaluated based on suitability, cost and feasibility.

All of this is going on while enterprises continue to make significant investments in traditional IT.

The reality is, for all but the newest companies, migration will be an incremental, multi-year journey. You won’t get there in one step. Modernized cloud native and legacy apps will coexist for the next 10-plus years, with business and IT value realized as each step is taken as part of a comprehensive digital transformation strategy.

Migration to cloud is a marathon, not a sprint. The question is, how can you accelerate and simplify that journey?

First, why migrate (and why not)?

Why migrate? Don’t move to the cloud because everyone else is, or you believe it could “automagically” save on infrastructure costs. However, if cloud is part of an overall change in how IT operates – creating more flexibility, agility, and the ability to respond quickly to changing business circumstances – you are on the right track.

Many organizations begin their migration efforts by rehosting an easy workload, but the highest value applications are in the functional areas where you want the most innovation and are the most amenable to change, such as client facing or internal business systems – or both.

Remember, not every application is a candidate for migration. Consider:

  • Large, stable, existing applications are probably a lower priority, until or unless you need to refresh hardware or the underlying infrastructure.
  • Security issues. Today’s hybrid, multi-cloud reality has IT leaders wrestling with how to move and manage workloads and apps between clouds efficiently without creating security risks. Sometimes this is more fear than reality, but in some cases, private cloud is the answer.
  • The impact of network performance on the migrated application. If the application is not designed as cloud native, consider network latency (lag) when you’re designing the system. If you are not located in a larger metropolitan area, complex tasks may take long to be received or processed. Applications that use overlapping data probably should be moved together.

 

Know your technical debt
One of the major challenges in moving to cloud is dealing with your organization’s ‘technical debt.’ If you’ve ever put off a project with the intent to finish it later, you have incurred technical debt.  If you are behind on software versions, you have technical debt. And if you took short-cuts like hard-coding variables to get code to work ‘for now’; you definitely have technical debt!

Today, many enterprise workloads are drowning in technical debt. Migrating or refactoring workloads and applications to the cloud is probably the best way to pay off that technical debt – while improving flexibility and agility. Understanding software currency, release levels and requirements for underlying middleware, database and operating system are crucial before you begin.

Lift and shift, refactor or modernization?

Business growth in a digital world requires innovation and the ability to leverage data for competitive advantage. Cloud makes that possible by removing infrastructure costs and transforming enterprise processes. There are several approaches to take:

  • Replace: When considering the “build vs purchase” question, decide if you really need to build a proprietary, cloud-based solution – for things like CRM or ERP — or if you can leverage a “born on the cloud” packaged solution? (If a package does most of what you want, why re-invent the wheel?)
  • Rehost – Lift and Shift: This is the easiest way to migrate to the cloud. Recently developed applications are often “cloud ready” and can be easily moved to the cloud using a container or virtual machine with no modifications required.
  • Refactor: Refactoring (or redeveloping) an existing application to take advantage of cloud-native functionality can make it more efficient, scalable, maintainable or reusable. Or you can make minimal changes by removing some dependencies on mainframe while avoiding the cost of completely rewriting the program.
  • Rebuild – Application modernization using microservices: Leverage microservices and containers to build a cloud solution based on an existing application.

The American Airlines modernization story

The reality is, you will use all of these techniques, depending on your application mix and how you intend to use them going forward.

Take American Airlines, who used this combined approach to save money and improve customer service. Most of us have endured a flight cancellation due to weather events. IBM helped American Airlines build a mobile Dynamic Rebooking app on the IBM Cloud to vastly improve the customer experience. Behind the scenes in parallel, using the agile, product-focused Garage method, American Airlines migrated core VMware applications from its legacy environment to IBM IaaS in just four months. The result? Major capital cost savings while ensuring secure integration with back-end systems.

This is a great example of a large enterprise leveraging cloud to digitally transform their business quickly, through a mix of cloud-native innovation development, lift-and-shift migration and modernization of important business functions with microservices.

How to evaluate application readiness

To determine the complexity of moving legacy applications to cloud, ask questions such as:

  1. Is it mission critical?
  2. How complex and time-consuming will the move to cloud be?
  3. What is the value generated to the business by being able to scale the application? The greater the need to scale, the higher the migration priority.
  4. How frequently are you changing or innovating in this business area? The greater the innovation required, the more value there is in moving to cloud.
  5. How secure is the data and where should that data reside? If your application is linked to other high priority applications, it is advisable to move it as a bundle.

Determining migration priorities

IBM doesn’t use a one-size-fits-all approach to cloud migration. With a focus on enterprise innovation, data privacy, security, and your specific business priorities, IBM uses a matrix that evaluates complexity, time to value and frequency of updates to create a cost-benefit analysis showing which applications should move to cloud first, be retired, or kept on traditional IT (for now).

The evaluation of migration priorities is stored in a database that can be queried, revisited and revised on a regular basis. As the centre of “data gravity” shifts in your environment, priorities will also shift, so data and database dependencies are identified to ensure that all complimentary tools/datasets are migrated to the same cloud to optimize integration.

 

Take the next step in the journey 

One of the main reasons that companies accrue technical debt is that their IT departments are already overwhelmed with everyday tasks. An experienced cloud migration partner can accelerate your switch to cloud and help you avoid costly mistakes along the way.

If your company’s application portfolio is more than five years old, not built for the cloud, nor optimized for containers, yet digital transformation is your top priority, it’s time to think about taking the next step in the multi-year journey of migration to the cloud – and the path from complexity to simplicity. 

Watch the video Tips for a Successful Cloud Migration

Read the blog Cloud migration checklist: 5 steps to a successful journey

Explore the benefits of Moving your applications to the cloud  

Experience the Garage

 

 

[1] IDC Canada’s PaaS Ecosystem Research Program’s 2018 survey on PaaS Adoption in Canada, January 2018),

Explaining the power of microservices (without the jargon)

No doubt you’ve heard the buzz about microservices, and you are probably wondering what all the excitement is about. Far from just being another IT buzzword, microservices are absolutely crucial for application development on the cloud. I’d like to explain how microservices architecture can create new value for business – often in ways you had never previously imagined.

 I’ve been in IT a long time. The ability to reuse code has been the holy grail of application development my entire career. Subroutines, object-oriented programming, object libraries, SOA – these were all supposed to be the magic bullet for reuse. We may not have reached the final answer, but microservices is one of the biggest steps forward in years.

Think of microservices as the logical extension of long-term trends in the evolution of software development. It’s a simple, yet powerful concept that is making all the difference for cloud-native application development.

Microservices architecture is a new approach to software development that creates very small modules containing data and functionality that can be easily combined, reused and scaled in various ways. Application services are broken up into small, independent functions, allowing developers to rapidly build applications, add new features, or launch new services. When combined with containerization, microservices can scale up and down depending on the need of the moment.

An analogy for non-techies

I like to explain microservices architecture using the analogy of a house. Think of your house as an ‘application’ or business system. In traditional, monolithic application development, the front door and back door of the house are the only ways to get in or out. Accessing ‘functionality’ in the house, such as the kitchen, meant following the floor plan – through the front door, down the hall, and so on.

project2
On the left, the traditional ‘monolithic’ house.  On the right, if you could take a microservices approach to your house, how it might scale after a party.  (diagram credit: Eric Dymond)

With microservices, the house itself is radically redesigned, so that individual functions such as the dishwasher or a bedroom are available in any quantity you want, in one simple step, from wherever you are. Having a weekend party? Get instant access to five dishwashers and three extra bedrooms, then scale back to normal operations when you’re finished. Reuse or recombine functionality in any way you want!

That’s the power of microservice architecture.

Why microservices are here to stay

Complex applications built from a set of modular components are faster and easier to develop, adapt, and scale to meet demand, and take up fewer resources. Developers have the freedom to focus only on their piece of the project, which means continuous integration and development are built into microservices architecture, while virtually eliminating infrastructure risk. If one component fails, it’s easy to isolate and fix it while the rest of the application keeps on ticking.

 To recap:

  • Microservices architecture splits large applications into (much) smaller pieces that exist independently of each other.
  • Each microservice does one thing and does it very well.
  • Microservices offer a fast, flexible and efficient approach to building, deploying, and updating individual parts of an enterprise application, streamlining application development and updates.
  • Security based on industry standards is built into each microservice, so it’s already there when you recombine or reuse the component.

A word about APIs and containers

Microservices are most powerful when they are  containerized. Think of a shipping container, which is used to quickly and efficiently load and transport cargo around the world. Putting microservices into a container lets you build a powerful system that gives you all the functionality you need, since the container gives you both scalability and replicability. The most common way to implement this is using Docker containers and using Kubernetes to orchestrate, monitor, manage, and scale microservices.

Microservices use application program interfaces (APIs) as gateways to access an application’s data or use an application’s functionality. APIs are how the world’s electronics, applications, and web pages are linked up to work together. It is the combination of microservices (public and private) plus containers that gives developers the scalability needed to rapidly add new value, features and functionality.

Why microservices are revolutionary

The 2019 IDC FutureScape Report says that the digital economy is driving the shift to modular, distributed, cloud-native technologies. It predicts that by 2022, 90% of all applications will be using microservices architectures.

That’s not surprising, when you consider what microservices can do for businesses.

Consider a very simple example. Not too long ago, company web sites contained static maps that showed their location. To get there, you needed a paper map. Today, a single mapping app such as Google Maps (a third party, microservice-based API) shows the company location along with dynamic, real-time suggested routes and predicted travel times for walking, driving, or transit. Not only is this revolutionary, it’s a win-win-win: it saves developers the effort of reinventing a mapping app every time; it gives consumers fast, customized information; and it is a huge win for the company who developed the product.

The opportunity is enormous

I believe that many organizations have not yet grasped the breadth of opportunity awaiting them with microservices architecture. They hear the buzzwords, but they aren’t clear on the value it brings to the business. Let me elaborate.

Not only are microservices at the frontier of cloud application development, they are the most powerful way to move the valuable functionality in your legacy applications onto the cloud. No need to move your 50-year-old legacy payroll solution to the cloud all at once to experience the benefits. Take out the piece that is scalable and reusable for other business needs, turn it into a microservice, then build or refactor the rest of the system over time.

Imagine taking a great idea from your finance application, combining it with another idea from your HR application, and creating a new, powerful solution that nobody had thought of before. It’s possible with microservices architecture.

Business leaders ask us how they can get the same kind of competitive edge. We have been thrilled to help large enterprise clients rapidly gain new functionality and create new business models using containerized microservices architecture on the cloud.

In one sense, microservices is just a new word for reuse and scalability in IT, but these days, multi-million-dollar business are stitching together publicly available microservices with their own solutions and ideas to disrupt and topple entrenched industries. Who knows what the next industry disruptor will be?

Next up: Migrating applications to the cloud

Most companies are starting to build cloud-native apps using microservices architecture, but it’s also a key component of a good strategy to migrate legacy applications to the cloud. Everyone’s journey has its own twists and turns, but to reap the greatest benefit, you need to refactor and redesign your application as you migrate it and modernize it for the cloud.

I’ll be talking about cloud migration in my next blog. Stay tuned!

Want more detail on this topic?

Read this helpful overview of microservices.

Watch the video “What are microservices?”

Explore the benefits of application modernization.

IBM offers Cloud Garage workshops, assessments and more.

 

 

 

 

“Stay Calm on the ‘Last’ Day” – the final (?) Paddling and Projects Post

I got two pieces of advice when I first started canoeing with friends. The first was “expect wind in your face and rain every day ‘, which was the starting point of this blog series. The second item that has stayed with me all these years and is relevant to projects was to “stay calm on the last day.”

canoe-crop

When I asked what my friend Graham meant by that or why he was saying that he highlighted:

  • The last day is often the toughest day of the trip. You are tired, you have a full day of paddling, repacking the cars, plus a long drive to get home.
  • You’ve will have been together with a group of people who you have different relationships, some you don’t know very well, for a long time
  • You will be tired, dirty, want some clean clothes, and a chair with a back and legs, something better than a log to sit on. Maybe a craving for something as simple as cold milk in a glass.

It’s easy in that scenario to let tensions or frustration get the better of you and say or do something you might regret in the long-term (even if it feels good in the here and now).

At the end of a trip it is particularly easy to let something slip if you’ve been holding it in for a long time.

In the same way, we all need to be able to keep our emotions in check when we get tired or the going gets tough on a project.  I confess that this is much easier for me to say than to do. Particularly on the big troubled projects that I’ve been brought in to, to help get them back on track. But the same thing process is at work. You get tired and easily triggered. It goes back to getting the frequent micro breaks, taking a deep breath… and staying calm on the last day.

When I started this sequence of blog posts on ‘paddling and projects’ it was the middle of winter. Now my canoe is back in the water, its time to do real paddling!

Here’s the complete list of ‘Paddling and Projects – Lesson’s Learned’ in summary form that we’ve explored in these blog posts:

1.    Expect wind in your face and rain every day Plan for problems; have contingency
2.    Make sure you have the right experts on your project Its not about ‘all senior’; its about balance in the team.  Do you have ‘just-enough’ expertise?
3.    Everyone has a role, Know your role, do more, carry your fair share Understand your role; take on more when you can
4.    Do you trust the person planning the route;

–      if I had seen the video, I wouldn’t have come;

–      The group moves at the speed of the slowest person

Understand the plan & whether the resources are capable of achieving it; provide constructive criticism to fill the gaps
5.    Innovators are often mocked before they are copied. So are the people who resist change. Embrace change; look for the benefit of change
6.    Take planned and unplanned breaks Take opportunities to recharge
7.    Be the early warning system Don’t assume everyone else sees the risks you see; don’t be afraid to highlight risks; bring a solution
8.    If you want to see the beautiful sites few have seen, You have to carry a heavy load & you have to go off the beaten path No client pays us $20m to go for a walk in the park; if it wasn’t hard it wouldn’t be transformative
9.    Don’t watch the end of the lake, you see progress by what you pass Make sure that there are frequent meaningful milestones to measure progress
10. Any fool can be uncomfortable in the woods Methodology is important; follow a method to achieve maximum benefit
11. A leatherman is the wrong tool for every job Get and use the right tools to execute your project
12. Don’t take cheap chocolate or mediocre wine into the woods Know your trade-offs -Understand what’s most important, when out of time / money; what’s the best thing for the client / /for the business
13. Maybe someone moved the hydro wires Usually the simplest answer is the correct one; test your assumptions regularly
14. Stay calm on the last day

 

Don’t let stress get you down; find ways to reduce stress (like canoeing!)

Maybe someone moved the hydro wires – Paddling and Projects (7)

Two short lessons in this blog.

  • First, test your assumptions, the simplest explanation is usually correct
  • Second, know what your most important tradeoffs are

This story gets repeated every time there is a question of exactly where we are.  The first time the canoe group went to Quetico, a park in the north-west of Ontario near the Manitoba border, the lakes were bigger than we were used to, and by the time that we had crossed a lake, they weren’t sure which Bay they were in.  The portages in Quetico aren’t marked, so you really need to figure it out from the map and your surroundings.  That didn’t stop people from having strong opinions about where they were.

One person was insistent that we had to be in a bay that the map showed power transmission  lines running across.  There were no wires to be seen.  He was so confident he was right he argued that ‘maybe someone moved the hydro lines’.

Which is the most likely:  that the wires were moved in the middle of nowhere, or that some one isn’t where they think?

We all get blinded by our assumptions. We need to validate them constantly; we need to take in new information, and we need to admit that the most simple answer is usually correct.  And when we are lost or wrong, we can’t keep justifying our position with more and more outrageous assumptions. Instead we adjust our position as new data comes to light.

Tradeoffs – don’t take cheap chocolate into the woods

On the canoe trip,  we eat (expensive) Lindt Chocolate as a treat after dinner.  The cheeses we snack on at lunch are double smoked gouda,  or 10—year plus aged cheddars.  I couldn’t believe it one time when we pulled out a hunk of cheese – the same size as a large cheddar you might buy at the supermarket – and someone remarked it was $50 worth of memolet.  It is delicious, by the way, and we take it with us every time now.

The pancakes get real maple syrup.

IMG_2189

After camp is set up, we’re more likely to drink Vodka or single Malt scotch than wine.

When you have to carry everything in a pack on your back, the ratio of weight and size (or density) to pleasure and/or utility become the most important tradeoffs.  A trip is only 4-5 days so splurging on more expensive, smaller items won’t break the bank.  And if you want to relax with a drink at the end of the day, it is better to drink some Vodka and water (or Tang) from the lake than lug five times the volume of wine or even worse – beer. There are space limitations in the canoe, too.

Similarly, in your project, know what’s most important to the team. To the business.  What can be traded off to get the maximum value within the budget.  Often businesses try to constrain everything.

I want it fast; I want it cheap; I want it great, and I want unlimited scope.  For a fixed price. Its not realistic.  There are always tradeoffs.

One of the great benefits of Agile techniques – and how these 2 lessons tie together – is the ability to constantly adjust priorities based on new information. Each sprint or iteration is an option to reset, refocus on what’s most important. But to do that, you need to be aware and not blinded by your assumptions, and you need to know what’s most important and what can be traded off.

 

 

 

“Any fool can be uncomfortable in the woods” – Paddling and Projects lessons learned (6)

This story happened before I joined this core group of canoeists, but it probably gets re-told every year.  Early in his camping experience, my friend Graham was surprised when someone brought out a down vest on a camping trip in the late summer. It was getting cooler as the evening came on and he wished he could have one.  When Graham asked about carrying winter clothing on a canoe trip on a summer day , the answer was ‘any fool can be uncomfortable in the woods.’

The down vest is light, it can be rolled up and used as a pillow.  It’s a great tradeoff.

The point here is that there are many tips and techniques that can make canoeing more comfortable. If you follow the process properly, you can be comfortable regardless of whether it rains or shines, regardless of the temperature.  Like you were born to it.

We’ve brought hammocks, inflatable couches, and enough tarps to keep the wind out and the rain off the kitchen area at the same time. Layers that allow you to keep warm or cool off.  We plan our route so that we avoid big open water or make sure we hit it early in the day when the wind is usually lighter.  There is a right way to pack your knapsack and canoe so that everything fits and is easy to get in and out.

h1

 

 

The analogy in IT projects would be method.  We have methodologies that help make the journey easier.  Are we following them?  Or are we stumbling around, shivering in a t-shirt on a cold and rainy day?

Like method, the right tool for the right job is just as important in canoeing as it is in consulting.

When camping, we have dedicated stoves, pots and pans.  A saw that collapses into a tube to be carried easily in a pack.  A water filtration system that cleans the water before drinking.

Even our canoe. The Voyageur is an example of the right tool for the right job. It’s based on the  Prospector hull style and it is one of the most popular type of tripping canoe’s.  It has a high gunnel (the side of the canoe) which makes it great for carrying lots of weight and still be safe if the waves get high.  You can see it cut through the water more easily than the rentals we sometimes use.  A Voyageur can carry large amounts of gear while being maneuverable enough for rapids – which we mostly avoid. This makes it a superb large capacity wilderness boat. But those high gunnels also mean it can get blown around a lot if you are paddling by yourself on a windy day. No tool is perfect for everything.

467

Other people would choose the ultra-light 35 lb canoe.  But they are constrained in the amount of gear that they can carry and we’ve seen those boats with a hull cracked as they went over a beaver dam.

So make sure you have right tools for your project. And be wary of all-purpose tools that have breadth but no depth…. If they’re not the right tool for a single job, they are the wrong tool for every job!

 

Don’t watch the far end of the lake, you see your progress by what you pass (Paddling and Projects)

Whenever I show pictures from a canoe trip, I invariably get the question “you were there?” with the tone implying a sense of envy. The lakes and rivers are so beautiful. Whether it is some cascade we are portaging around, the mist in the morning or a beautiful sunset, we see spectacular sites. Killarney, with its white rock and deep blue water, it particularly gorgeous in the fall when the colours are changing. We’ve been there when the colours deepen every day. It is glorious.

But these places are all off the beaten path.  It is hard work to paddle and portage to get to see this.  My back aches, my arms are tired. Sometimes I can get pretty grumpy.  But for me its more than worth it.

In the same way, the big achievements in IT projects or in consulting… an NPS of 10 on a difficult project, an external or internal recognition award, IDEA, completing a complex project on-time on budget for a client – these are hard work.  We all want to see the press release or be in the management meeting where a senior executive says “we couldn’t have done it without you.’  but that takes hard work each and every day.

An old friend and colleague of mine, Leslie Kulokas, who retired from IBM always said, “if it was easy, they would have monkeys doing it”.  Clients hire us for their projects because it is difficult.  When you do a great job in a tough situation, sometimes knowing that they couldn’t get it done without you is the only reward.  But just like in the canoe, the payoff is worth it.

One of the reasons a canoe trip is tough is that a canoe doesn’t really move very fast.  Certainly not compared to a motor boat or a car.  When you start out across a large lake or down a long river, it can look like you will never get across to the other side. Conversely, it is easy to look only at your hand on the paddle and your own contribution. Again it can feel insufficient to the task.

  • If you keep staring at the end of the lake, it feels like nothing is changing.
  • But if you look to the sides, you will see the scenery slide by pretty quickly.
  • The view changes constantly if you are close to shore.

And then when you look back at the long view a few minutes later, it seems like you are much closer.

It’s the same in a long project.  If you are constantly looking at the final destination, it might seem like you aren’t making progress. And it is sometimes hard to see how your individual contribution builds to the final goal. But if you have frequent milestones – and you know that those milestones actually lead where you are going – then you can measure your progress more accurately and have a real sense of progress. To me this is one of the biggest benefits of Agile projects – frequent milestones, frequent celebration of success, and an opportunity to both re-energize and re-assess your direction.

Whether it is the end of a portage, or out in the middle of the lake, we take lots of breaks during the day to re-energize. We plan our routes to so that there is time to set up camp, make dinner, clean up and still have time to relax before it gets too dark.

It’s easy to run out of steam when you are pushing hard and it is important to keep hydrated and your sugar levels up.

Similarly, on projects we need to take care of our people.  There is an ebb and flow to every project, and we need to make sure our team is getting the equivalent of a red licorice or a Werther now and then.  Whether it is disconnecting via training, vacation, or a mini break with a team pot-luck or evening event…. we need to make sure the answer isn’t always ‘more right now.’

 

“If I had seen the video, I wouldn’t have come”- matching your plan to your capabilities – Paddling and Projects (4)

One of the most important conditions for a successful project is matching the ambition of your goals with the capabilities of your team. It’s a lesson that a canoe trip really drives home.

map extract

If you look at the map extract above, it shows a section of Algonquin park that we’ve gone canoeing through several times. The red and black lines represent portages – where you carry your canoe, then go back and carry your pack – across the portage. The distances are marked in metres. With four adults, the minimum is everyone walks the route two times – ½ way with the canoe, ½ way back, then all the way with your pack and any other gear. The second person does the reverse – takes his or her pack all the way, then comes back ½ way and picks up the canoe.

So your ‘friend’ for example, could plan a circular route that started in the lake at the bottom centre of the map (which is Opeongo in Algonquin Park), takes a 2180 metre portage, a short paddle, then a 1330 m portage to Red Rock Lake, camp one night on Redrock, then a 3085m portage parallel to the Crow River another campsite. Then a final 1390m portage to complete the circle back to Opeongo. We’d practically be taking the canoes with us on hiking trip!

Did I mention that the canoes are about 25 kg (55 lbs) and the packs upwards of 35? When we need to rent canoes we pay extra to get the ultra-light 16 kg canoes. And of course, the reason you have to portage is that the river can’t be paddled – it has rapids, waterfalls, or un-passable swamps… that means the portage route has hills to climb, and often bogs to walk through too. (It could be worse – The black lines mean the portage is not well maintained, and usually even tougher.)

This route shown is actually tough but doable for me when it is just four strong adults. That first portage is very flat. But when you have young children, you can’t make them carry the canoe, and perhaps not even all of their gear. So now you’re doing each portage route at least three or four times. That’s why I say a group moves at the speed of its slowest person. The project equivalent of course, is the critical path.

One time, early in my canoeing tenure, my friend Graham planned a route so difficult that another friend said as he was trying to climb up and down yet another hill with his pack ‘you know, if I had seen the video, I wouldn’t have come.’

Similarly, on your project, everyone needs to know what the plan is, everyone needs to buy into the plan, and know where the tough spots are, and whether you have a team that can achieve all the milestones. A bit of stretch is great – it encourages the team to work, to learn and to improve. One of the things I like about a canoe trip is the feeling of stretching my skills and pushing myself to do more. But looking at a plan and thinking ‘no way we can do’ that is demotivating. And unlike a canoe trip, where once you are away from the shore you are pretty much committed, on your project, people who decide “if I had seen the video, I wouldn’t have come” actually do have choices.

Innovators are often mocked before they are copied – Paddling and Projects (3)

Two quick ideas this week continuing my theme of lessons from my experiences in canoeing and how they apply to projects:

  • Innovators are often mocked before they are copied
  • Don’t assume everyone else sees the shoals that you see

 

Innovators are often mocked before they are copied

When I first started canoeing, one of the other guys on the trip brought a headlamp rather than a regular flashlight. It was the first time any of the group had used one. We all laughed, thought it was goofy, asked him if he was planning a career in coal-mining, and made similar jokes. You might be able guess the kind of things we thought he might need two hands free in the dark for.

The next year, three of the four of us had head-lamps and now I was the odd-man. I remember at one point the rest of the group in the evening all turned their headlights on, then blinded me by all looking me in the eye at the same time! The reality is that cooking, getting into a sleeping bag, fixing your tent or hammock… at night it is all easier if you have a light, and still have your hands free.

Two other big examples from canoeing trips followed similar patterns – someone brought it, we made jokes, then later we all bought in:

  • The middle photo shows a Thermarest chair. A Thermarest is a self-inflating mattress that you sleep on top of. It provides both increased comfort and extra insulation when sleeping. They are mandatory for overnight canoe trips. But there is also an optional kit to turn it into a chair so when you are sitting around the campsite you are much more comfortable than just sitting on a log that happens to be there.
  • The sleeping hammock has replaced the tent. With a tarp over it (not shown), it is just as rainproof as a tent. And you are off the ground, so it is better for your back. You don’t have to worry about finding ‘level ground’, which as far as I can tell is a myth in the wilderness. And a hammock is much lighter than a tent with all the poles and pegs. So, it is a big improvement over the tents that we used to carry.

Be careful it isn’t the same on your project. Don’t discount a new idea because ‘that’s not the way we’ve always done it’. I remember the first time I worked on an agile project which was back in 2003. The objections we got… ‘no pre-set scope’? ‘no commitment except to finish something in a given time?’ … ‘we just add stuff to the backlog indefinitely?’ No way we’re going to agree to that! How would we do scope control? How do you know when you’re done?

And yet, because the results are there, agile is actually better in many situations and more popular than traditional waterfall for IT projects. What’s the next idea that you’re laughing at?

Here’s a quick way to check just how much you or your organization company new ideas. Think about some modern technologies: In 2019 the list includes A.I., Cloud, Blockchain, IOT.  How many are you using? Did your firm start working with at least some of these technologies five years ago, two years ago… or are they on the agenda for a small pilot next year?

 

Don’t assume everyone else sees the shoals that you see

The picture on the left shows the bottom side of my beautiful new canoe after three canoe trips. All of those white lines you see are the result of us ‘bottoming out’. Hitting a rock – big or small – a submerged stump or log, or just hitting the beach too fast. Sometimes in these parks you can see what we call ‘indicators’ … bits of paint left on a rock in the water where someone else’s canoe has scraped the bottom and left a trail. The person in the bow (front) is supposed to be looking for fast water, rocks or stumps, or the water getting too shallow. So that we can steer around them.

The photo on the right shows 2 friends of mine who thought that they could run up a small rapid… they took on more than they were capable of. The canoe dumped. They claimed that an invisible giant muskie hit the side of the boat!

Just like in consulting, you need to call out risks and shoals ahead. Any project can take some minor issues. My canoe doesn’t leak, and I could keep hitting the same types of rocks for many years without ever needing a repair. But don’t assume the person steering your project sees the same risks you do. Everyone needs to call out what they see and take the right steps to avoid the problem.

The picture of my friends dumping their canoe is a good example of risk mitigation. They tried to climb this rapid with the canoe empty. We had left our packs at camp and were going out to do some fishing. So, they got to try something new in a low risk scenario.

Its all about the team, & having the right person in the right role – Paddling and Projects: Lessons Learned (2)

Its always important to understand the level of expertise on any project and the same is true in canoeing. In my work life I’ve been in leadership roles for more than 20 years, but I am in a quite different role out on a canoe trip.

K&G1.png

I’ve been going canoeing with the same core of people for 25 years.  We all met through IT consulting.  On the left is my friend Graham. He is a great big data and analytics thought leader, by the way. But the most important thing is:  he’s been canoeing for 50 years. He actually built his own canoe in high school.  His summer job as a teenager was to work as a summer camp counselor where he was the ‘tripper’ – taking younger kids out on overnight canoe trips. I think he also worked 1 summer as a junior ranger –  then he took 2 years of forestry at university.

On the right is Ken.  Ken was a senior technical sales manager at Oracle for many years. Knows a ton about database and high-performance transaction management. More importantly, he has a bachelor’s degree in freshwater biology – or as he likes to say, a degree in fishing.  He did field studies on the impact of acid rain on the lakes in Killarney Provincial Park and then spent a winter the Hudson Bay Barrens doing other research before switching to IT.  He’s been canoeing longer than Graham.  On top of that, both of them do the majority of the cooking in their families and I consider them to be gourmet cooks.

With that level of skill available, we’re capable of taking on pretty much any trip.  Whether it was high winds and waves out on the lake, a tough portage, or some unexpected bad weather, there is nothing they can’t handle.

On a project, its not necessarily about having that level of expertise.  What is important though, its understanding the capabilities of your team, and planning your trip –  or your project – accordingly.

Similarly, about 6-7 years ago, I realized my son Alex, who is now our most common ‘4th canoeist’, was better at sterning the canoe than I am.  The person in the back (the stern) is the captain, deciding the route across the lake, and steering.

Alex1.png

Of course, you want the best person on the best job… so he is in charge our our boat.  But what does that leave me to do?  My friends are experts, my son has surpassed me… But someone needs to paddle in the bow (front).  Around the campsite, the gourmet chefs want to cook. But I can still do the dishes, be the sous-chef peeling carrots, filter the water, gather and cut-up the wood.  And carry my share in my pack and the canoe.

Its about getting the work done the best way, not about taking the most glamorous or fun job for yourself.  When we are packing the bags the start of each day before getting in the canoe, you can tell the people that you want to go canoeing with. They come up to the kitchen area and start taking food, the stove, pots and pans… whatever they can get into their knapsack.

The ones you don’t want to camp with are the ones who wait until you say ‘can anyone carry these final few vegetables that I can’t quite get into my pack’ ? and then it turns out that their pack is ½ empty.

It’s the same on a project.  Always try to do more than asked for. Look for jobs that aren’t being done and do them.   We all want the people on our team who are going to finish their own work, and then keep trying to take on more.

By the way, there are lots of times on a trip when I do cook , or stern the canoe.  You have to keep those skills sharp too just in case.

Expect Wind in your Face and Rain Every day – Paddling and Projects: Lessons Learned (1)

For about 25 years I’ve been a frequent camper and canoer (canoeist?) in the big provincial parks in Ontario. I’ve gone pretty much every year, and many years when my children were little I went twice – once on a family trip and once on a more difficult ‘just guys’ trip. As the kids got older the family and guys trips merged into one. So I’ve done maybe 40-ish trips in all. And most weekends in the summer I am out for at least a short paddle in my canoe at our family cottage in Georgian Bay.

What has struck me over those years is that the lessons from paddling and the lessons of projects are often the same. I recently did a presentation on this topic and over the next few weeks I will share it as a series of blog posts, with each covering one or two ‘Paddling and Projects: Lessons Learned.

When I first started canoeing, I asked the friends that I was joining for some advice. They gave me some suggestions about the specific clothing I should have and the gear that I needed, and then they said

Expect wind in your face and rain every day.”

Not the best way to sell someone on a spending a week on a canoe trip where you need to be outside all the time, is it?

There were really 2 points being made here:

  • First, you need to have the right gear necessary to deal with any situation. You need to be able to layer up and down, to have a great raincoat etc. A similar comment was the need to have ‘wet clothes and dry clothes. No matter what, keep your dry clothes dry.’ The stuff you wear in the canoe might get damp – or soaked – but put it back on the next day rather than risk having nothing dry to wear in the evenings.
  • The second point is about your plan and expectations. If you expect perfection, you are certain to be disappointed. When you plan for problems, you are prepared ahead of time and not scrambling to figure out what to do.

In my experience overseeing big projects, when I review a project either during the initial planning, or if I am taking responsibility for something in mid-stream, one of the first questions I ask is ‘how much effort contingency have you accounted for?’ Almost invariably, the answer is ‘none’. So what we are saying is, we expect to do something we’ve probably never done before and we are going to do it perfectly the first time out. How realistic is that?  How perfectly do we understand this situation?

You might think that this isn’t relevant in Agile projects, But in each iteration, you need to be able to gauge your confidence in how well you understand the backlog items you’re committing to complete. And there are usually business expectations beyond the initial minimum viable product.

So you do need to consider if you have planned enough resource and time to deal with some delays and unexpected challenges in every project.