Momentum in software development is never a straight line

Development does not move forward with purpose like a marching band. It weaves, stumbles and staggers like a drunk heading towards the kebab shop #HoskWisdom

Projects don’t move in a straight line and project plans are rarely accurate. Software development is full of surprises, new requirements and changes no one ever predicts. It’s only the simplest projects with a clear scope and less than 5 people involved that go to plan. They are as a common as a 5 leaf clover.

Why are they wrong?

Recipe for success: under-promise and over-deliver. Kevin kelly

Projects do the opposite, they over promise and under deliver because the project/work is underestimated and the team’s ability to deliver is overestimated

Everyone wants to hear a lower numbers in days to deliver and cost, so that’s what they hear.

The lowest bid wins and the curse of the winner is to deliver the project to an impossible deadline. How does the project scope grow so much from the original requirements?

Requirements are not understood, with many missing requirements and lots which will change as the details become clearer. It’s impossible to identify all the low level requirements from high-level requirements e.g. you discover more as you go into detail and use what’s been built.

The perfect project plan is POSSIBLE if one first documents a list of ALL the UNKNOWNS. Bill Langley

Software development uses the inside view to estimate work and create project plans. These estimates have little margin of safety and don’t assume bugs, problems or change of requirements..

Most software development projects are late. Everyone who has worked on software projects knows that rarely go to plan, yet all plans are made using the optimistic estimates that assume no problems, no changes in mind and no change in requirements.

Why will this new project be different? It won’t, it’s just what everyone wants to hear and wishes for.

It’s only in fairy tales that emperor’s get told they are naked and the project will take longer than estimated.

If you are doubting this point, then think

  • Were the requirements different by the end of the project, then the start?
  • Did the requirements grow in scope and size?
  • Did the project have unexpected problems (technical, people, political)?
  • Did the project change its mind or priorities?
  • Were there any design mistakes?

More people, the longer the delivery time, the wider the scope, all increase the probability of unforeseen delays. The bigger the project, the bigger the impact they can have.

What really happens

Everyone forgets how hard it is to create software from requirements. Creative processes do not run smoothly, there are missteps, stumbles, mistakes and wrong turns.

Every old system replaced was moulded into its current state via many bugs, feedback and discussions until the team worked out how the system needed to work. Therefore most rewrites take longer than estimated because they remove lots of code they think they don’t need but was added to fix a bug.

Chesterton’s fence says never remove a fence until you know what it was there for, was it keeping things out or keeping things in?

Chesterton’s Fence: A Lesson in Second Order Thinking

Code is full of Chesterton’s fence but it removed by developers making the code efficient without understanding its purpose. Few people understand all parts of a system, which is why changing it often leads to fixing one bug only to create another in a different part of the system.

Creating a complex system is done by focusing on the details when you get to that part and finding there are complexities you didn’t see when you looked at it from a high level.

This is how it works, this is the process. Like the drunk stumbling to the kebab shop, it’s not a direct line, it’s a wibbly wobbly works of discovery, full of surprises.

Momentum on projects should be constant, steady progress. The problems, questions and new requirements become the way they are the method you create the system needed, which is different from the system we thought was needed at the start.

As Ryan Holiday says — The obstacle is the way

What’s the problem

The problem is plans give a project a false sense of control, plans give an incorrect expectation on delivery timelines and cost.

Plans are underestimated and extending then causes pain. Re-planning multiple times in small increments wastes time and results in iterations of incorrect project plans. The common response to tight deadlines is to go faster, reduce quality but this speeds creation of code but takes longer to get to production.

Quality code gets into production faster and it reduces complexity, which reduces time spent on maintenance.

Simple example
A company wants case management and a portal, integrated with their phone system.

Dataverse and Powerapps portal is a sensible choice

The requirements quickly grow

  • Call popping grows into web chat, the possibility of chatbots is mentioned
  • Case management is for 4 teams
  • 4 different SLAs
  • There are experts for different areas
  • An escalation process
  • Some cases need approval
  • We need to send letters out and they need an integration
  • Documents need to be stored
  • Documents need to be uploaded from the portal
  • Some documents can only be viewed by certain users

What seems like a straightforward piece of work keeps growing as more details are uncovered. At a high level the out of the box solutions met the requirements but high level requirements are not the real requirements.

Conclusion

Projects don’t move in a straight line to their goal, the scope expands as high-level requirements are broken into low-level requirements and everyone understands how the system needs to work.

Blood, sweat and tears are put into creating software and any large project. I look back on projects and marvel at the painful process, but am proud of what we achieved and how everyone worked as a team.

Creating software is one of the most frustrating and rewarding activities you can attempt, and they rarely go in a straight line or as planned.

Why experienced developers are worth the money

Pascal Habermann

“Experience is what you get when you didn’t get what you wanted” ― Randy Pausch

Development experienced is earned the hard way by trying, failing and trying again until you get it right.

Developing isn’t easy and anyone who says it is will soon be humbled by the process. Senior developers are expensive but inexperienced developers will cost you more with late projects.Not all experience is equal and when you get to lead developer you need standards and leadership (values which are also learnt)

Experience is what you get when development didn’t work as planned or when something goes wrong. Experience is gained by working outside your comfort zone, on areas you haven’t done before. The cost of developing is making mistakes and a slower development speed because of the trial-and-error nature of learning.

In development theory is good but practical experience gets work done. It’s not until you create code in a new language or framework that you know you can do it.

Why is development hard?

The same approach doesn’t always work every time because the requirements are unique, the people involved are unique and the solution is unique. A creative process, involving people, communication and creating functionality that needs to work individually and as a complete solution. There are unknowns that cause errors. Errors and mistakes are a part of the process, going wrong and fixing it. Feedback is the fastest way forward for the solution and the developer growing their skills. 

Experienced developers limit the risk of things going wrong badly. They avoid more problems and fix the problems they find quicker.

The cost of learning

New Languages and frameworks are the same and yet different. The key concepts are the same, but each has its own syntax and processes. It takes time to learn how it works and the processes around deploying, creating and debugging etc.

The cost of learning is mistakes, getting it wrong will help you understand how to get it right. This is the on boarding cost developers need to pay to gain experience. Experience allows you to avoid future mistakes. In theory there is no difference between theory and practice, no difference between knowledge and creating code and customization.

In practice there is a big knowing what to do and doing it are very different and doing it will throw many unexpected challenges. Therefore practical experience is more valuable than theoretical knowledge.

An example is IT professionals with certifications, it shows they have the knowledge but doesn’t give any sign they can use that knowledge effectively.

This article talks about why C# developers struggle to learn Dynamics 365 Why .NET-C# developers struggle with Dynamics 365 Development

Why is experience valuable

Project plans are based on developers working at a steady speed. If the team makes decent progress, then we deliver the functionality roughly on time.

When bigger problems arise and progress slows significantly, then projects soon fall behind. This is when leaders and customer get alarmed.

Experienced developers don’t get blocked and through experienced have learnt to tackle problems logically and find the cause. Experienced developers, slow down and ask the right questions to resolve the problem.

Experienced developer reduce the big mistakes, resolve the smaller mistakes and deliver at a consistent rate. This allows projects to be delivered on time.

Conclusion

There is no shortcut to mastery, you earn it by doing, and it’s the fastest way to learn.

Experience is valuable because until you have done something, you don’t know how difficult it is and you don’t know all the mistakes you are going to make. Experience reduces the potential for making mistakes.

Other articles you might like

original blog post – Why experienced developers are worth the money

The greatest danger to developers

hai-sharks

“the greatest danger you face is your mind growing soft and your eye getting dull.” ― 50 Cent, The 50th Law

The greatest danger to developers is to stop being curious, stop learning and stop keeping up with new technology. The day you stop learning is the day you start your journey towards retirement.

Slow death

How do you slowly make development harder? falling behind the latest changes one day at a time. The environment evolves and your skills need to change with it.

I worked with a Java developer who stopped taking an interesting in new versions of Java, new frameworks, new best practices and just came to work, wrote the code needed and went home. He slowly found development harder and needed more help understanding frameworks and projects. Eventually they couldn’t find a project for him to work on and he become increasingly scared of new projects.

Developers are craftsman, you are never the master and always the student. There will constantly be new languages, new ways of doing things, new services, new tools, new best practices, and you have to be interested enough to keep investing time to learn.

Like the frog slowly being boiled, the developers who stop learning are slowly being boiled

“Standing still is the fastest way of moving backwards in a rapidly changing world.” — Lauren Bacall

Dynamics on premise versus Dynamics 365 online

When Dynamics 365 online came out it was inferior to the on-premise version and you couldn’t do the same level of complexity. Many developers chose to not invest the time in learning Dynamics 365 online. Slowly Online functionality caught up and then with Azure, no code solutions (Power Platform) and Microsoft pushing it hard, it become the number one choice of customers..

When online caught up it was very appealing to customers to choose online because Dynamics 365 is a service and it means that people could get rid of their servers and the technical experts who look after those servers. Microsoft would guarantee to keep the service up all the time, Microsoft would stop virus and deal with security.

Companies who didn’t change with environment found themselves behind, they hadn’t trained people to have skills for online projects; they had no experience in online projects.

Those companies who didn’t keep learning were left behind. Like starting a race and giving everyone else in the race a head start.

No code revolution

Microsoft is moving into business applications and has created a powerful no code/low code functionality with Power Automate.

In the early stage some people ignored it, used old workflows or continued writing C# code and JavaScript code.

The next step Microsoft added connectors and kept improving Power Automate and then it was a powerful tool that could almost match the functionality of C#. The cost to create and maintain customisations was lower and could be developed by Power users /citizen developers.

If you weren’t interested or didn’t learning then you started the race behind all those who jumped on it at the start. If you don’t go down this route then you are swimming against the Microsoft tide.

Survival of the fittest

“It is not the strongest of the species that survives, nor the most intelligent; it is the one most adaptable to change.” — Charles Darwin

What I’m talking about is adapting to the changes in environment, if you don’t adapt then you become less effective in the new environment. The longer you resist changing the less effective you become in the changed environment.

Your skills were great in the previous environment but the development environment has upped the version, moved online and is changing to low code solutions. If you aren’t keeping up then you are slowly becoming less useful.

Stay curious

Take opportunities to be more curious and open, explore the truth. Imagine you don’t know anything. Expand your knowledge and experience and embrace new functionality as a new opportunity. Expose yourself to different ideas, go outside of your comfort zone.

When you stop learning, you start to become less adapted to the environment and will slowly become less useful.

The rate of change is speeding up and evolving your skills as technology advances will happen more frequently and be more important. Read the article below to see why

Google Director Of Engineering: This is how fast the world will change in ten years

Interesting articles

article originally published The greatest danger to developers

Development can be torturous

Egg Hammer

Never give up. Today is hard, tomorrow will be worse, but the day after tomorrow will be sunshine. Jack Ma

Douglas Adam the brilliant writer of the awesome — Hitch Hikers guide to the galaxy at times felt writing a torturous process, to the extent he wrote himself a note to pick himself up, featured in this article in the Guardian.

“Writing isn’t so bad really when you get through the worry. Forget about the worry, just press on. Don’t be embarrassed about the bad bits. Don’t strain at them,” The Hitchhiker’s Guide to the Galaxy author wrote to himself. “Writing can be good. You attack it, don’t let it attack you. You can get pleasure out of it. You can certainly do very well for yourself with it!”

Doing things we love can at times be difficult, the creative process has lows and highs. It’s during those hard times we have to remind ourselves that creating is difficult but the end product will be worth it.

Development can be torturous

There are many things which make development difficult, particularly the many occasions you are pushed out of your comfort zone and

  • New Integrations
  • Data migration being underestimated by a factor of 3
  • A new programming language
  • Impossible deadlines
  • Being sold as an expert on something you have never used
  • triaging bugs
  • Being measured on progress on a daily basis in public e.g. the daily standup
  • Not clear on the business purpose behind
  • Making a mistake and bug being written on your customisation and lack of testing
  • Development working against you, someone else code breaking yours, builds broken, services down

my personal favourite is after you have created exactly what was asked for, the customer decides they don’t want it like that and you have to spend the next day removing what you did the previous day.

Positive attitude

Development is great fun, you create something that works from a document with how they would like it to work. You bring ideas to life and create a system someone can use and in some cases make their working life better.

Attack development, get stuck into and keep trying, failing, adjusting until you make progress.

Development is a puzzle to be solved, you are going to find a way or make a way.

I will either find a way or make one — Hannibal

A positive mindset lets you take the initiative and don’t let problems happen to you, you tackle the problems. Take control and own the situation and get the advantage of being aggressive and setting the direction.

It takes considerable effort to be good at development but the reward is in what you create.

Other articles you might like

Evolution of solutions in Dataverse/Dynamics 365

Evolution

“Those who do not move, do not notice their chains” Rosa Luxemburg

Dynamics 365 professionals see every problem as something to be solved by Dynamics 365 plugin or workflow. The environment has changed and now the best solution might not need Dataverse database but just a Canvas app.

This article — Aliens in our midst made me think about how we think about solutions in Dataverse/Dynamics 365 and how new functionality can change the way we view the problem and solution.

Thoughts change the way you look at and understand life. Once your brain has been stretched it can never go back to it’s original shape and is forever changed.

We could all achieve more but choose to do less and live a life less challenged and easy.

Evolution

I have worked on many Dynamics projects Dynamics professionals thinking and architecture could needs to evolve. The solutions most Dynamics 365 professionals create are centered around Dynamics 365 functionality, solutions are anchored around around Dynamics 365.

We need to step back get to the key business requirements/objectives and view all the tools available in Azure.

Too many people are doing the same solutions they have been for the last 5 years but it’s time to use the full power and Power platform and Azure. The same thinking and approach will produce the same results.

Why .NET developers struggle with Dynamics 365 Development — BLOG LINK

When Microsoft moved to Dynamics 365 as service, hosting workflows and plugins used the Dynamics 365 service. Microsoft instead of developing this, creating Power Automate, PowerApps, Logic Apps. These can be used by Dataverse and stand alone Power Apps without a database.

For most Dynamics 365 developers, Dynamics 365 is the solution. It’s not anymore and they need to get up to speed with the tools and possibilities in Azure, AI, Power Platform.

First principles

Dynamics 365 developers should try a 1st principles approach to projects

How Elon Musk Thinks: The First Principles Method

“I think it’s important to reason from first principles rather than by analogy. The normal way we conduct our lives is we reason by analogy. [With analogy] we are doing this because it’s like something else that was done, or it is like what other people are doing. [With first principles] you boil things down to the most fundamental truths…and then reason up from there.” Elon Musk

What are the benefit of “first principles” thinking?

It allows you to innovate in clear leaps, rather than building small improvements onto something that already exists. Musk gives an example of the first automobile. While everyone else was trying to improve horse-drawn carriages, someone looked at the fundamentals of transportation and the combustion engine in order to create a car.

The first principles approach takes more energy but the solutions are more focused to the business needs.

Great article on First principles by James Clear

First principles with Dynamics 365 development

Dynamics 365 consultants create solutions using Workflows, developers create solutions using plugins and JavaScript #HoskCodeWisdom

This is how they have been taught and what they have always done. It’s been successful in the past and will probably work in the future.

It’s a solution first, requirements second, look at alternatives if we have to way of thinking.

This thinking is a man with a hammer thinking, when you have a hammer every problem looks like a nail. The previous successful projects using workflows and plugins encouraged those developers to keep doing it.

This created difficulties when Power Automate and Azure Logic apps were first introduced. Developers were reluctant to move to Power Automate and Logic apps because they didn’t have experience in these area.

This article helps move you thinking in the right direction — Dataverse is not a database

Business first not technology

Link requirements to objectives/goals, too many projects are lead by the technology of the solution, this is because in the past technology was limited as to what could be practically delivered.

Business don’t care what technology is used to create the solution, they care the solution helps their business and helps individuals do their jobs easier.

The only limitation to the scope and breath of solutions is the knowledge of the solution architect. The barrier to an effective solution is their knowledge or the business and knowing what the purpose of the functionality is.

Projects should be business lead and solve the problems of the business, not create solutions around technology because it veers away from the business needs and takes the focus away from the business needs.

Other articles you might like

Why experienced developers are worth the money

“Experience is what you get when you didn’t get what you wanted .” ― Randy Pausch

Development experienced is earned the hard way by trying, failing and trying again until you get it right.

Developing isn’t easy and anyone who says it is will soon be humbled by the process. Senior developers are expensive but inexperienced developers will cost you more with late projects. Not all experience is equal and when you get to lead developer you need standards and leadership (values which are also learnt)

Experience is what you get when development didn’t work as planned or when something goes wrong. Experience is gained by working outside your comfort zone, on areas you haven’t done before. The cost of developing is making mistakes and a slower development speed because of the trial-and-error nature of learning.

In development theory is good but practical experience gets work done. It’s not until you create code in a new language or framework that you know you can do it.

Why is development hard?

The same approach doesn’t always work every time because the requirements are unique, the people involved are unique and the solution is unique. A creative process, involving people, communication and creating functionality that needs to work individually and as a complete solution. There are unknowns that cause errors. Errors and mistakes are a part of the process, going wrong and fixing it. Feedback is the fastest way forward for the solution and the developer growing their skills. Experienced developers limit the risk of things going wrong badly. They avoid more problems and fix the problems they find quicker.

The cost of learning

New Languages and frameworks are the same and yet different. The key concepts are the same, but each has its own syntax and processes. It takes time to learn how it works and the processes around deploying, creating and debugging etc.

The cost of learning is mistakes, getting it wrong will help you understand how to get it right. This is the on boarding cost developers need to pay to gain experience. Experience allows you to avoid future mistakes. In theory there is no difference between theory and practice, no difference between knowledge and creating code and customization.

In practice there is a big knowing what to do and doing it are very different and doing it will throw many unexpected challenges. Therefore practical experience is more valuable than theoretical knowledge.

An example is IT professionals with certifications, it shows they have the knowledge but doesn’t give any sign they can use that knowledge effectively.

This article talks about why C# developers struggle to learn Dynamics 365 Why .NET-C# developers struggle with Dynamics 365 Development

Why is experience valuable

Project plans are based on developers working at a steady speed. If the team makes decent progress, then we deliver the functionality roughly on time.

When bigger problems arise and progress slows significantly, then projects soon fall behind. This is when leaders and customer get alarmed.

Experienced developers don’t get blocked and through experienced have learnt to tackle problems logically and find the cause. Experienced developers, slow down and ask the right questions to resolve the problem.

Experienced developer reduce the big mistakes, resolve the smaller mistakes and deliver at a consistent rate. This allows projects to be delivered on time.

Conclusion

There is no shortcut to mastery, you earn it by doing, and it’s the fastest way to learn.

Experience is valuable because until you have done something, you don’t know how difficult it is and you don’t know all the mistakes you are going to make. Experience reduces the potential for making mistakes.

Other articles you might like

What’s your fifth risk? — Unexpected problem cause big problems

Gladson Xavier

“Life is not what you expect: it is made up of the most unexpected twists and turns” — Ilaiyaraaja

Projects are fertile breeding grounds for problems. Ingredients such as groups of people working to tight deadlines, using new technology/features with no experience and lots of activities happening at the same time.

Some problems go off like a hand grenade, grab everyone’s attention and demand to be resolved quickly. Other problems hide in the background, sleeping, and then when everyone is looking the other way they unexpectedly cause enormous problems.

What’s the unexpected risk that will disrupt your project?

Like being hit by a car you didn’t see, the surprise doesn’t give you time to plan or react.

The Fifth Risk

In Michael Lewis’s book the The Fifth Risk: Undoing Democract it puts forward the idea president trump is a risk manager and the government official who works in the many departments manages risk.

Lewis interviews government officials in roles such as the department of energy and asks them for their top five risks. Most people can reel of four risks quickly but when they get to the fifth, they struggle and have to do more thinking. Lewis highlights this

“And I thought, that’s the fifth. The risk you’re attending to, the risk that’s top of mind, is not likely the thing that’s going to actually kill you. The fifth risk is a scary one because it’s the thing you’re not paying attention to.”

The fifth risk is a long-term risk that with gradual mismanagement could grow into a large problem. What are the risks you aren’t expecting, what’s my fifth risk on the projects and work.

Example

It works, it works, it works, then boom it doesn’t work. these problems cosy up close to you causing you to let your guard down before they go wrong with devastating effect. No one saw the big problem until it exploded.

I have seen many ignored problems suddenly turn into a large problem. A project left on debugging on a Dynamics server, every day it would log out hundreds of lines of logs which no one looked at. This was a small problem, which someone was going to get around to fixing at some point. One day no one could create any new records in Dynamics, the problem it turned out was there was no more space on the Dynamics server because it was full of 2 years of log files no one was looking at.

The coronavirus was unexpected but so were peoples reaction. If everyone had brought the same amount of food, pasta and toilet roles as before, no one would have run out. Instead some people started buying extra, which panicked others to buying extra which resulted in empty shelves and some people who couldn’t buy any toilet roll.

“On February 1, 2003, the U.S. space shuttle Columbia disintegrated when reentering the Earth’s atmosphere, killing all seven crew memberes. Columbia broke up because a piece of foam insultation broke off during the launch and damaged the shuttle’s ability to protect itself from heat on re-entry. The problem of the foam debris was not new, but since nothing bad had happened in the past, the engineers overlooked the issue. Rather than considering the risks from the debris. NASA took the lack of problems as evidence that everything was ok.” Michael J. Mauboussin — Think Twice: Harnessing the Power of Counterintuition

The nature of these problems is they don’t initially seem worth worrying about, people overlook these problems as minor annoyances and something to clean up later when we have more time. Some problem can leave a gap open for a bigger problem to occur or the small compounding of the problem grows until it becomes a big problem.

People don’t see them coming

A common problem on IT projects is the lack of standards or lowing of standards. Initially the effect is hidden by time, the complexity of the solution gradually increases. Standards code and customisations are written consistently to drive quality.

No standards creates customisations/code in different ways, different naming. The system becomes harder to understand, taking more time to debug and extend. Every new customisation takes longer, more bugs appear, and each bug takes longer to resolve.

Eventually the cumulative build up of low quality code/customisations will result in the customer considering moving to a new supplier and rewriting the system. Death by a 1000 poor lines of code rather than one fatal bug.

Covid-19 — Coronavirus

All nations were warned of a pandemic, many did test runs and found they did poorly but few changed the infrastructure to prepare for an outbreak. When a pandemic strikes, it’s too late to prepare because it can quickly overwhelms the heath service.

The best time to fix a hole in your roof is when it’s sunny.

The shortages in PPE equipment, ventilators , testing facilities, tests could have all been prepared for. It’s time to build

The fifth risk in different areas

Projects

  1. Relationship with the customer
  2. Scope growing out of control
  3. Missing requirements
  4. Impossible deadlines
  5. Low standards
  6. poor leadership
  7. technical limitations

Company — Dynamics partner

  1. reduced sales
  2. High churn rate/people leaving
  3. Poor leadership/lack of engagement
  4. No strategy to win
  5. Behind the technology curve

Solution architect

  1. Missing non function requirements
  2. A solution that doesn’t work
  3. A solution not scalable
  4. Bottle necks
  5. Uncontrolled scope
  6. Your knowledge not keeping track with technical change

Developer

  1. The project leadership
  2. poor estimates
  3. Technical debt
  4. Poor requirements and missing requirement

Conclusion

The fifth risk will be the small changes which don’t seem important enough to stop. This gives them time to grow and hide, until one day a massive problem explodes and chaos ensues.

The problem that causes the most disruption is the one you didn’t expect.

Know where you are an expert and where you are an idiot

Geralt

Most people are expert in a few areas, get overconfident and think they are experts in everything. #HoskWisdom

It takes confidence to admit you are not an expert in all areas and you should defer to someone who is. There is no shortcut to becoming an expert, it takes years of learning, experience and practice to have a deep level of understanding on a subject. Don’t tell an expert what to do it in their area of expertise because you become an idiot who over rules experts and in the long term this doesn’t work out well.

Admit you don’t know

It takes confidence to say you don’t know and most people will go with a solution they heard from someone or seems reasonable. Few people defer to an expert and many people are afraid to ask a question which could make them look stupid, instead preferring to live without that clarification and knowledge.

“A remarkable aspect of your mental life is that you are rarely stumped … The normal state of your mind is that you have intuitive feelings and opinions about almost everything that comes your way. You like or dislike people long before you know much about them; you trust or distrust strangers without knowing why; you feel that an enterprise is bound to succeed without analyzing it.” — Daniel Kahneman

Are brain is built to function without having all the knowledge, so it’s the emphasis is on our thinking and decisions to catch the moments when we mind is moving forward with the information it has.

Catch your brain forming quick opinions and avoid over ruling experts, instead use questions to understand the strengths and weaknesses of your ideas.

Circle of competence

You are might be thinking why is this important? why should I care?

When we move outside our circle of competence, we increase the chances of mistakes and create problems for ourselves. When we stick to what we are good at, we are working in an environment that is suited to our skills, when we move out we are potentially working in an environment where we aren’t suited and don’t have the knowledge or skills to operate successfully.

Tiger Woods is great at golf but if he was challenged by a below average computer programmer to write a computer program, he would lose. If Tiger Woods opened a restaurant there is no guarantee that it would be successful because Tiger Woods is an expert in golf not cooking (that I know of). His expertise in Golf won’t help him with his restaurant.

“As they say in poker, “If you’ve been in the game 30 minutes and you don’t know who the patsy is, you’re the patsy.” — Warren Buffett

Overruling experts

It’s easy for individuals to become the patsy. I worked on an IT project where the customer put forward and insisted on a technical solution.

I mentioned that you hired us technical experts and this isn’t the solution we would recommend. The individual had worked with that technical solution in a previous company but didn’t have the knowledge of the current technical solution to know it was a bad idea.

The technical solution turned out to work slowly and later that person complained about it. We referred back to the discussion and evidence that we didn’t recommend this solution and they overruled us and took the responsibility for the decision. The end result was a change request to implement the solution we previously suggested.

You don’t know what you don’t know

A little bit of knowledge gives false confidence that we are knowledgeable in it but this is because you don’t know the detail. Experts consider decisions and a greater depth that novices don’t even consider.

We all have a few tricks

In the article from Farnam Street blog 12 Life Lessons From Mathematician and Philosopher Gian-Carlo Rota there is a section called Every mathematician has only a few tricks

“We don’t need to be amazing at everything to do high-quality work. The smartest and most successful people are often only good at a few things — or even one thing. Their secret is that they maximize those strengths and don’t get distracted. They define their circle of competence and don’t attempt things they’re not good at if there’s any room to double down further on what’s already going well.” Shane Parrish

The article quotes Gian-Carlo Rota

“mathematicians, even the very best, also rely on a few tricks which they use over and over”

Playing and managing

There are lots of world class footballers who assume their expertise in playing football and working with great managers will enable them to become a great manager themselves. The skill of playing football and managing a football team are completely different.

Playing is an individual skill — fitness, tactics, position specialization and how you as individual fit in the team

Managing is tactics, motivation, recruitment, etc. Managing is considering the team and all the people involved (not just playing staff).

Conclusion

Don’t try to be an expert in everything, understand what areas you are the expert and what areas you are not. Who in the team has more experience and knowledge in this area and ask their opinion. Are brains make it easy for us to have an opinion but we have to check it’s not leading us astray or creating problems for us.

It’s hard to admit we don’t know but you will get more respect for doing it. Saying you don’t know isn’t a sign a weakness, it’s an honest assessment that this isn’t your area of expertise and to defer to an expert in this area.

We have an edge when dealing with areas we are an expert in, when we move outside of our expertise we have no edge and shouldn’t play there.

Know where you are an expert and where you are an idiot

Interesting articles

Why IT projects are underestimated

Image for post
image from reshot

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction. Bill GatesThe UK government’s response to Covid shows how easy it is to underestimate a project and how you can overestimate your effort. Project takes longer, costs more and can often fail.

IT projects underestimate effort, complexity and time (all contribute to cost), whilst overestimate the effectiveness of everyone involved and the benefits.

How do underestimate?

Low estimates are what everyone wants to hear at the start of the project. Everyone wants to hear it the project will be quick, simple, with a fixed cost and lots of benefits. The people involved will find ways to support this line of thinking

  • The bid is decided on cost (e.g. lowest wins), not if it covers everything.
  • The high level requirements are more basic than the eventual low level requirements but this scope enlargement is not factored into the plan
  • Leadership wants a low bid and quick estimate

The goal of the team making the bid is to get a low cost and small timeline. The initial goal is accepting a low bid not the goal of delivering the project and often the team responsible is different.

No one gets in trouble for telling someone what they want to hear. There is no incentive for team choosing the bid to accept a more detailed plan that is more likely to deliver a successful project.

I seen the process where the project bid I helped put forward was rejected for a bid that had a lower cost but missed many of the steps that I felt the project would need to be delivered successfully. It made me wonder why they didn’t ask the other bid why they didn’t have this included in their plan and it highlighted problems to me. The goal of the team accepting the bids was to get the best value for money bid not the bid most likely to deliver the project successfully.

Incentives and performance reporting influences the behaviours and choices

The Distorting Power of Incentives

“Never, ever, think about something else when you should be thinking about the power of incentives.” Charlie Munger

Projects and plans

IT projects involve groups of people working together to deadlines, making quick decisions, making mistakes, replanning and creating multiple smaller systems which work together as a whole.

Projects involve customer teams/individuals doing an unfamiliar role and working to faster timelines than they are used to.

Plans are made but in projects the plans quickly go stale and our not in sync with the environment. Plans need to be updated regularly, a process most people don’t like doing because it involves telling leadership it’s going to take longer (plans never get shorter).

Why plans go wrong

It’s impossible to create a new system on paper and work out all the small details needed in the system. Why? You don’t know exactly how a system needs to work in detail at the start, you have to learn and iterate.

Initial system will have logical and technical bugs. No plans include this work because you don’t plan for the system to built incorrectly or unknown problems. This is where adding contingency is important but this is often viewed as a luxury that optimistically the planner hopes won’t happen to their project (spoiler alert — it will)

A system on paper/plan isn’t the system needed by the user. You only find this when it’s used and through feedback from using the system and trying to do their jobs.

Goals, priorities and working practices change over time, these change the order and the scope of plans.

UK government Covid response

Covid shows how easy it is to underestimate the difficulties in creating a new system or new process from scratch because we forget existing systems are built over many years of small improvements to a business process and system.

This article from the Guardian discusses what we should learn from the Covid crisis.

The article has a great quote
There is reason to be sceptical about the contention that Britain would have endured a less fraught crisis if only ministers had possessed more dictatorial powers. Things for which the NHS has responsibility have generally gone very well, a notable example being the smooth implementation of the vaccination programme. Things over which politicians have direct control — such as test and trace, the provision of protective equipment, the timing of lockdowns, the enforcement of quarantining measures and border controls — have not been glittering testimonials to the speed and quality of ministerial decision-making. It is not self-evident that the best answer to the health service’s many challenges is more Matt Hancock

NHS processes

  • Vaccination
  • Emergency plans to deal with hospitals that hit capacity

Government new initiatives and systems

  • Track and trace
  • Provision of protective equipment
  • Lockdowns
  • Boarder control and quarantine

The existing NHS systems and people responded excellently because the existing and had experience and skilled people running them. The hospitals expanded to deliver care despite hospitals hitting capacity (how many businesses could do that?) and the vaccination rollout has happen at a rapid pace.

To put the vaccination rollout into perspective, it’s the fastest national vaccination in history of the UK.

The systems which didn’t work was the new ones setup because it takes more time, effort and expertise. Most importantly you need the system, processes need to be tried to get the feedback and fix the problems.

During the implementation of a large project there is a need to make quick and decisive decisions. You will need to change plans to reflect reality, when your plan needs to change due to the environment and feedback.

Communicating and leading are vital skills on large projects, you have to be able to understand and resolve problems at rapid speed in order to not lose momentum. These are not common skills and often the lack of them is the cause of projects to slowly go wrong, 1 day at a time.

The outside view

We forget the the difficulty in creating and delivering new projects, the false steps, the problems, the bugs and changes. A great way to see how long something will take is to view it with the outside view, e.g. how long did similar projects take.

Early in the Covid pandemic , there were wild timelines given for a vaccine, if you look at the long view, you could see at best it would take 18 months

The outside view — how long will it take to create a vaccine for Covid-19?

Conclusion

Incentives cause projects to underestimated in complexity and over estimated with regards to the ability of the team to deliver them.

Unforseen problems are not taken into account because everyone wants to hear the project is going to be finished at the soonest possible time for the least amount of money.

Those who raise problems can be blamed for those problems and there is no incentive or benefit to raising problems.

There is a usually a big difference between the time we think a project will take and how long a project really takes.

Related articles

How to discuss ambitious project plans

picture from here

“Someone’s sitting in the shade today because someone planted a tree a long time ago.” — Warren Buffett

There is a time on most projects, where the project plan is going wrong and the deadlines won’t be met.

The pressure is to change the plan to deliver on time, add more people, work faster, pull out all the stops and hit the date.

The simple response is to agree with the new plan, try to implement it and see if it works. This is the answer everyone wants to hear, particularly leadership.

But is this the best thing you can do for the project?

Should you try and deliver a plan that won’t work or should you create a realistic plan that can be delivered?

There was a saying

“No one got fired for buying an IBM”

Let’s create a similar saying :

“No one got fired for going along with the updated aggressive plan”

The problem with agreeing to a plan that won’t work, is it causes more problems. Plans comprise many dependent actions and if one part of the plan is late, the project is late. The project delivers when its last dependent activity is complete.

or to put it another way ,

The project can deliver at the speed of its slowest team

What can you do?

Most people think of control as telling people what to do, but you don’t need to tell people what to do, to change their ideas. You can change people’s ideas by asking them questions, highlighting areas and helping them to come to new conclusions.

In this situation, we want to clarify if this plan will work or if it’s a hopeful plan. Hope is not a strategy, but it can keep everyone following a plan that work.

Scenario

Let’s take a standard project scenario

We are developing a feature to deliver into production, to create the feature we need to

  • Create requirements
  • Refine requirements
  • Create user stories or FDD
  • Customer signs off User stories or FDD
  • Development feature
  • Test feature

For just one feature there are multiple activities, people and decisions that could go wrong. You always have unforeseen problems that could occur.

It takes more effort than we estimate to deliver one feature, which

Adding more people

Adding more people rarely makes the project go faster, particularly in the short term. Adding more people to a project is like adding more people to a meeting, it doesn’t make it go faster and adds a communication overhead.

A meeting with four people decides more effectively than a meeting with 20 people.

Why adding more people to a project doesn’t make it go faster

The outside view

Aggressive plans are built on hope, highlight this by asking questions

What estimates is this plan built on?

We want a plan that’s built on estimates, not just dates.

The plan should be built on the individual actions needed to complete the work and on estimates of the current team doing those tasks.

Take earlier similar examples of feature earlier on the project and compare its timelines to see if they are sensible.

“Previous feature B, took 3 months to get to production. What are we doing now that means we will deliver this in 2 months”

Take the previous time and ask why it will be different? What is the project going to do different to deliver it quicker? The project should be able to justify the increased speed of delivery, otherwise they are deluding themselves and creating a plan that won’t happen.

What needs to happen

Switch the focus on what needs to happen for the plan to be successful and ask the question.

What needs to happen for this plan to be successful?

Focus on the deadlines people need to met?

What can’t happen e.g. any unexpected problems

Decisions which need to be made and by when

Create alternatives

Time is a tool, an effective way to use it is to create alternate plans whilst you have time and upfront. This helps you prepare. When you need to act under pressure, you don’t need to think up an alternative plan on the spot because you did it when you had more time.

The army and marines create a PACE plan

PACE plan

Primary plan

Alternative plan

Contingency plan

Emergency plan

Summary

When a project goes off track, there is pressure to create a plan to put it back on track. Options should be considered but its important to create a realistic plan because another plan failing will cause morale to drop.

Most people can sense if a plan is unrealistic, it drains morale. A realistic plan can boost morale because it shows how the project and people on it can overcome problems and get back to the plan. People enjoy working on a successful project

Help everyone on the project create a realistic plan by asking the right questions and highlighting the areas where it may go wrong.