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?


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.


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


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.

Thinking beyond the project

Focus on business, people, customers and then technology, in that order #HoskWisdom

when we focus on a delivering the project, we miss the goal of the project. Think beyond the project, focus on the helping the business be successful and use technology to help.


Projects involve people, time and expense, they take time and effort. The measurement of success becomes delivering the project and this becomes the focus of the project. Everyone focuses on delivering the project, forgetting the real goal of a project. Our focus becomes narrow that we miss the goal and are unprepared for the real problems that occur after.

Old tactics

In the book Boyd: The Fighter Pilot Who Changed the Art of War talking about how the marines focus on creating a beachhead.

“Once, while the groups wrestled with how to put a landing force on the shores of Iran, Boyd realized the Marines were placing inordinate emphasis on how to establish a beachhead. “That beachhead is looming bigger and bigger,” he said. “You guys are paying too much attention to terrain. The focus should be on the enemy. Fight the enemy, not the terrain.””

A beach head is temporary line created and then reinforced quickly with numbers, the attacking force can push on and take the beach. This is a world war 1 tactic where most battles were head on and wars of attrition.

John Boyd refers to this “Hey diddle diddle, straight up the middle”

The goal isn’t creating a beachhead, the focus shouldn’t be on the terrain, the goal is to attack the enemy, beat the enemy and landing a beachhead is small part of the plan.

These are world war 1 tactics, they didn’t take into account the change in weapons, communications, the enemy or the situation. How many times do people try to run a project, just like the previous project.

In the article — Thinking beyond the beachhead it has this quote

“The main lesson at Normandy, I think, is relevant to the point that I am trying to make. Planners went into the operation focusing on getting on the beach, a task that they anticipated would be the major problem. As it turned out, the problem was getting off the beach!”

When we focus on the wrong area, we focus are thinking to that area. We need to step back and see the larger goal and how it all fits into a larger system.

Tactics should be tailored to the situation, not just pushing the strategy used in the previous war against a different opponent.

What happens on projects?

The goal of a project should be to help the business become more efficient, solve their problems. Technology should be one of part of the improvements, aligned with the business processes, the people and business goals.

Design thinking starts looking at the how the business works, their problems and goals. It looks at the pain points with the current ways of working and how to improve customer service. The initial work looks at the business holistically and on creative solutions.

In many projects the focus is on replacing the existing systems and new technology..

The focus is on

  • The existing legacy system
  • Technology
  • Delivering the project on time

The focus is on the technology and the project , we focus on the beachhead and not the enemy.


Every customer, business and project are unique, there isn’t a template that delivers a successful project. You need to observe the environment, requirements, problems, people, industry, company and ways of working, use this to create a unique approach.

The environment changes, the approach needs to reflect this, you cannot use a static approach too every project because it sometimes it will work and sometimes it won’t.


A plan and approach will be created at the start of the project, this will quickly be wrong because the information on the project changes. Your plan needs to be based on reality, you need to make decisions with the latest information.


Think beyond the project, focus on the business, people, customers and technology, in that order. There isn’t a standard template, you have to focus on the goals and problems of the business. Understand the business first and creation the solution second.

Are people on the project waving or drowning?

Sometimes it’s those who don’t ask for help, who need it most #HoskWisdom

The difference between someone in water waving and drowning is small, but the difference could lead to life and death. How many times do you see people and teams complaining, but are they waving or drowning?

Conflicting teams

IT projects are stressful, delivered to tight deadlines. Teams need to get their work done, but depend on other teams to complete the project. Teams need to focus on their own work to ensure it’s done correctly, on time and to a high level. The dilemma to individual teams is if the other teams don’t finish their work, the complete solution won’t work. You can’t finish creating a human and have the legs and arms finished but no head and eyes.

  • Your team needs to complete work
  • You need to help other teams with information and shared design
  • Obligation to the project to make sure all teams are working effectively

Waving not drowning

Complaining is a popular pastime on projects, individuals can create noise and distract others. The personal objectives of individuals can distort messaging and priorities


  • An individual or team can exaggerate their performance and contribution
  • A successful team can quietly get their work done (not
  • personal conflicts can lead to individuals complaining about other teams

Drowning not waving

People and teams who are drowning don’t always ask for help, they try to battle on, hoping things will turn around. In some situations those who are in a position of responsibility don’t want to admit they made a mistake, have a relationship with an individual involved and don’t want to make the change.

The simple choice is to stick with the status quo and not change because changes need to justification and if it goes wrong there will be criticism. You are less likely to be criticised for sticking with the current plan, which still might work. The original plan might be created by someone else, which gives less incentive to change the plan and take responsibility.

To admit you are drowning takes courage because you need to make yourself vulnerable and ask for help. It easier for others to notice a team/individual needs help but there needs to be incentives to want to improve.

It’s difficult for leaders to understand what is working and what isn’t because of the lack of clarity in reporting and feedback. There are two truths that can come to mind

* You can’t lead from an office

* You can fool people on the front line that things are going well

You need to get out and talk to people, find the pain points from the people doing their jobs and not just listen to the managers, plan and metrics being measured. The tendency will be for people to not publicise bad news or hide it but if you want to improve a project you to fix the parts not working as soon as possible.

Step back

There are always more tasks to do on a project, another report to write, meetings to attend. The constant motion stops you taking time to reflect, step back and see the bigger picture. A project is a complex system with lots of separate and dependent parts. Most of the time you deal with the symptoms of problems and not the root cause.

Peter Senge’s first law of The Fifth Discipline is “today’s problems were created by yesterdays solutions”, the second-order effects of changes are not always clear but can cause problems later on or in other places.

To assess your own performance you need to create some time to think, look at the project as a complex system and see where the problems are and assess your performance and contribution to these problems.

questions like these help

  • What do I need right now?
  • What would really help me?
  • What are my priorities?
  • What am I doing, that someone else should do or can do?

People problems don’t resolve themselves and need to be actively resolved, unless you are close it’s difficult to tell if the person is waving or drowning.

This post came from listening to the new Future Islands album and then finding this poem written by Steve Smith called Not Waving but Drowning, one paragraph is below

Not Waving but Drowning BY STEVIE SMITH

Nobody heard him, the dead man,

But still he lay moaning:

I was much further out than you thought

And not waving but drowning.

Poor chap, he always loved larking

And now he’s dead

It must have been too cold for him his heart gave way,

They said.

Oh, no no no, it was too cold always

(Still the dead one lay moaning)

I was much too far out all my life

And not waving but drowning.

Projects evolve to create the right solution

Requirements create estimates, estimates create plans, plans create projects, projects create problems because the requirements, estimates, plans and projects were wrong #HoskCodeWisdom

IT projects go wrong, you can’t avoid it but you can prepare for mistakes, get feedback helps you learn, improve and create a solution suited to the customer needs. You can’t get all the requirements up front, for a technical team to design and estimate a solution correctly and then deliver it without any significant problems is crazy.

The requirements and solution develop the more you investigate and build. The solution delivered at the end is never like the solution specified at the beginning. The plan you created at the start of the project is never correct, it evolves and changes along with the solution.

Requirements are never complete, requirements are missed, requirements are added, requirements are wrong and they requirements change as the project develops.

Estimates are not commitments, they are an estimate of effort based on the information at the time.

Plans are created with the assumption nothing will go wrong, changes won’t happen, people won’t leave and nothing significant will go wrong. Plans will always change, expect it and use it to your advantage.

Change is natural, change is positive, change will deliver the project which is needed, not the project which was estimated and planned with a minimum amount of information.

Make sure people are aware plans will change and deliver projects in smaller parts, incorporate feedback into your plans and deliver value early and often.

The goal of a project is to deliver a solution the business needs, not the solution specified in the plan when you had less knowledge and no feedback or experience. Don’t become to protective of your plan that it stops you changing.

Defining your project problems, helps you avoid them

All I want to know is how this project will fail, so I can avoid doing that #HoskWisdom

Project plans have goals, milestones and deliverables. They have optimistic paths into the future and run into trouble when the inevitable problems jump up and smash you in the face.

Predict your potential problems and you can resolve them before they become problems. Focus on what might go wrong and you can create plans to prepare for it. Do your thinking before the event when you have time and you will have the answers ready for when you have to act.

Mike Tyson warns of the danger of project plans

“Everyone has a plan, until you are punched in the face” — Mike Tyson

Predict your problems

The best person to predict the problems that might occur on the project you are working on, is the team working on the project. There are common problems, but each project can create completely new problems.

A popular method to predict problems is to perform a premortem, like a post mortem but before the death of your project 🙂

Premortems are effective because no one is to blame for potential problems, it encourages people to raise potential problems. Premortems can be more effective than post mortems because in a post mortem people are being defensive and protecting themselves rather than diagnosing the actual causes of the problems. Post Mortems can suffer from people rewriting history to support their actions and justify their actions.

Premortem’s help you find potential sources of failure and give you a chance to resolve small problems before they become big problems.

A premortem could start

  • “The production go live failed disastrously because…..” or “
  • “What are we nervous about”
  • “What could go wrong which would cause us the most problems”
  • “what’s like to go wrong”
  • “what’s the biggest risk”
  • “what happens if this person gets kidnapped”
  • The project was a colossal failure because…..”

The group can suggest reasons the project could fail, discuss the causes and what steps we can take to mitigate the problem. Focus on the top ten and work out what you can do to stop those problems from happening.

Plans go wrong and need to change, planning for problems lets react strategically if those problems occur. Planning for problems allows you to use time before the event to be ready during the event. When problems happen in an event, you don’t have time to think, which is why you should use the quiet time before to plan your response.

The best time to fix a roof is when the sun is shinning, not in a thunderstorm. The best time to plan for big problems in a one off event, is before the event has started. You can stop some problems from occuring, have plans for when other problems occur

Define your fears

I was watching a Tim Ferris TED talk — Why you should define your fears instead of your goals and a blog post — Fear-Setting: The Most Valuable Exercise I Do Every Month. which offers a similar approach

Define — prevent — prepare

  • Define: List the worst things that could happen or the significant problems
  • Prevent: List how you can stop the items above
  • Repair: If the worst happens, list how to repair each bad thing.
  • Have others resolved this problem or similar problems, learn from their experience and avoid their mistakes

If you think you don’t have time, what will be the cost of not doing this? unexpected problems ruin your day


Thinking about your project fears or what might go wrong is inverting the problem, it helps you avoid mistakes and prepare for them. There is a difference between knowing what problems could occur and preparing for them. Time is a tool and successful people use it to give them time to think. In the middle of a crises you don’t have time to think, so do your thinking before the crises hits.

The best time to plant a tree is 20 years ago, the second best time is today — Chinese proverb

The coronavirus is a good example, the countries which got hit from SARS prepared themselves for future pandemics by creating a plan, stock piling, upgrading hospitals and were ready to act quickly. The countries which had to tackle Covid-19 as it was happening were behind, tried to decide as they went, and responded slower.

Things to consider when using Flows for data migration

“Show me a ten-foot wall and I’ll show you an eleven-foot ladder” ― Peter Bevelin

Using Flow for data migration is easy but has limitations you should consider, these limitations can cause problems left the data migration in limbo, whilst waiting for the api limits for each day and Flows waking up and running

When you hit the daily limit for Flows, they stop working until the next day (when limit resets). 


  • Data migration can have lots of records and could take many days
  • Flows don’t fail, they queue them up
  • The only way to stop Flows triggering is to delete them or put the Dynamics 365 environment into admin mode.

There are examples where the Flow limits meant the Flows have been in a waiting state for 4 days due to hitting the throttling limit on a daily basis.

Flows are not just on Flow runs by actions inside the flow.

How did we get here with Flows

Microsoft initially had workflows which were hosted by Microsoft and used Async service on the Dynamics 365 server. There were no limits on workflows but from Microsoft’s perspective this isn’t great because these run on Microsoft resources and costs them to host and run them.

Microsoft created Flows, with greater functionality and built on Logic apps. Flows are a scalable, enterprise solution and with connections allow you to create Low code solutions and link systems together.

The benefit to Microsoft is the Flow runs are easily counted and Flows are hosted in Azure which is scalable. Microsoft pushed Dynamics 365 users to use Flows and warn that workflows will be deprecated sometime in the future. Flows allow Microsoft to estimate and control how much it costs to run Flows. Dynamics 365 online is a service, so Microsoft don’t want to have unlimited resource/compute for people.

Flows allow people to scale up and pay for what they use in classic Azure costing process. This initially seems unfair because we were used to no limits but paying for what you use is ultimately fair.

You get taxed one way or another with functionality and it’s not something you can resist. It’s important to align your solutions with Microsoft’s road map. If you resist and continue to use workflows because they are free then in the future you are creating a huge upgrading task.

Flow first

I have a Flow first attitude and workflow should not created on projects going forward. Many Dynamics 365 professionals resist this because they have Workflow skills and might not have created a flow yet. By default we don’t like change and stick with what we know.

Make them do it in a flow, it will be slow to start with but they will soon start to love Flows because they are more powerful

How to cancel flows

There isn’t any way to bulk cancel flows, it’s a one by one event. Flows queue up runs even if they are not enabled!! The only way to stop them is to delete them (and there is no way to bulk delete flows!!)

if you cancel a flow it doesn’t stop the flow running when the api threshold limit is refreshed when you hit a new day.

It’s possible you could be left with 1000’s of instances of flows left in a running state, with you waiting for refreshes of API limits. These could be days!

Deleting flows is only a choice if you have a solution with the flows in and more recommended with an automated release.

Logics apps?

Microsoft have created functionality to run Logic apps on your local machine and some talk that we should all be moving to Logic apps. This combined with an improved editor should make it easier for no code professionals to create logic apps.

I’m not sure about this or if it’s the direction of travel but at the moment Flows are easier because of the current environment connection that means the Flow can work in the environment it’s in and is easily deplorable.

What’s the usual data migration choice

The common tool I see used for data migration on large projects is Kingswaysoft. I haven’t used Scribe online but I believe it has similar functionality, so it depends on the expertise of your team.

Microsoft is moving to count the actions within a flow and step in a flow will be an action which you will have a limit

Dynamics 365 and replicating to an SQL database for reporting

Flow limit

The Flow limit is a topic that will increasingly come up in Dynamics 365 projects, as more projects hit the limit.

My feeling is the limit is a bit low, particularly considering the number of environments you can have in a large project.


Flows are awesome and combined with connections they are powering the no/low code revolution in Dynamics 365/Power Platform projects. Flows and Power Platform are replacing the bespoke .Net applications and Excel spreadsheets that can grow in companies.

Microsoft is starting to be tighter with the Flow limits and charging more in the future. This seems unfair because we are coming from not paying much but in reflection I tend to view the Azure/usage pricing as fair.

Currently the way Flows have some odd ways of work and the turning off functionality can be a nuisance because the runs are queued, waiting for you turn the flows back on. The only way round this is deleting the flow.

Avoid certainty and embrace inquiry

You control the decision, not the outcome #HoskWisdom

There are no right answers, there is only questions and finding out why. There is no certainty, we have questions, ideas and our ability to make good decisions.

The more you think you know, the less you question and the more assumptions affect your decisions.

When you believe you are an expert, you stop listening to other people because you believe there is nothing more to learn. This gives you less information to make decisions with and unable to adapt to changes.


“You cannot make progress without making decisions.” Jim Rohn

A good outcome can come from the wrong decision.

A bad outcome can come from a good decision.

The feedback we get from our decisions comes from the outcome but outcomes are not guaranteed with luck and other variables affecting the outcome. 

We can’t control the outcome but we can control are decision making process. There are occasions where people make the right decision with incorrect logic. This works in the short term because of probability and luck but in the long term the results are based on thinking and quality of your decision making process.

Long term success is based on your critical thinking skills and your ability to solve problems. Environments constantly change and the actions that brought you success yesterday might not work tomorrow.

System thinking says yesterdays solutions are tomorrows problems and this is due to second order effect, unintended outcomes and the environment changes.

You need to make decisions, reflect on the feedback and adjust if you need to.

Don’t be certain, question, clarify and find the why. Being curious helps you uncover information to make better decisions, inquiry helps clarify assumptions.

Certainty in your ideas, stops you changing and adapting to change. It can lead you down the wrong path and your ego can stop you changing your mind.

Situation changes and you have to align with it.

picture from here

Further reading

Why you should listen more than you talk

The Knowledge Project #89 — Maria Konnikova — Less Certainty, More Inquiry

Dynamics 365 October 2020 wave 2 error — Mobile Offline Profiles import: FAILURE: Mobile Offline Profiles import: FAILURE

I was on a project which was manually applying the October 2020 Wave 2 update and after saying this never go wrong, what happens, yep, it goes wrong.

The question is what do you when this happens. In reality you can only raise a Microsoft support ticket.

I raise a P1 with premier support and Microsoft do not reply for 2 and half hours, clearly their idea of a P1 is different to mine.

So I was poking round the system, which is not straight forward because with PowerApps portal there are at least 3 ways to do everything.

So I got to Environments →Dynamics 365 apps

I can see I have two apps with an update available. Of course pressing this button looks like it kicks of an install but nothing seemed to happen.

Image for post

So I look at solution history record in advanced find to see if any solution imports fail. and I find that one of the solution patches from Microsoft has been failing since 15/08/2020. Doesn’t Microsoft check?

Image for post

The error is

Mobile Offline Profiles import: FAILURE: Mobile Offline Profiles import: FAILURE

I found the same error somewhere else

Image for post

The mobile offline profile is if you have a canvas app and you enable it to go offline, which means it can work without internet by downloading data onto the device, e.g. a salesman using a tablet and having the app work offline.

In this case weren’t using offline functionality and the only canvas with offline enabled and the profile was Microsoft’s Field Service app.

I have had problems with the mobile offline profile before

Dynamics 365 — mobile offline profile error

It would surprise me if this is the problem but I didn’t really have any method to investigate. The way the patches are applied I can’t see the import logs to identify where the errors are.

What’s surprising is Microsoft best practices is not to use patches and yet they use them. They are pushing regular update of patches and some of them aren’t working and no one is informed or does anything about it!

Image for post

I will wait to see what the resolution is to the problem but it was frustrating because I couldn’t do much to investigate or fix it. The problem is with Microsoft updates and they will have to investigate.

Why you should listen more than you talk

“Never give reasons for what you think or do until you must. Maybe after a while, a better reason will pop into your head.” General William T. Sherman

When you are trying to impress people with words, the more you say, the more common you appear, and the less in control. Even if you are saying something banal, it will seem original if you make it vague, open-ended, and sphinxlike. Powerful people impress and intimidate by saying less. Robert Greene

The more someone talks the more you learn, the more we talk the more information we give away. Despite this, our inclination is to talk more than we listen. Listening lets us learn more about a situation, gather more information. Talking has the opposite effect, you give more information away.

Shut up and listen

The more people talk, the more points they make, the increased chance of contradicting themselves. The more points you make, the more ammunition you give to people to disagree with you, let them wonder what you think and give yourself room to change your mind.

We waste time by talking about things which aren’t important, focusing on the wrong areas, instead, keep quiet.

You learn by listening

When you speak you don’t learn. When you listen, you might hear extra information, a new idea, feelings or a new perspective. When you listen you learn.

What is the goal?

  • What is the goal of this discussion?
  • What is the motivation of the people?
  • What is being discussed?
  • What problem is being solved
  • What does the other person think?
  • Why do they think that?

When you listen it helps you understand what people think, why they think something and how they feel. Yet before they have time to speak, we are telling them about our ideas on the topic.

You produce better ideas if you explore problems, understand different perspectives, and gather more information before forming ideas. The earlier you speak the less information you have used to come to your conclusion and the great the chance of misunderstanding the situation.

Better solutions need you to listen and learn, if speed is the goal then talking can help you push forward a conversation and decision. The earlier you speak the less informed your answer will be.


There are no right or wrong solutions, each solution has strengths and weaknesses. Understanding different solutions from different perspectives allows you to create solutions by combining different ideas.

Silence makes people nervous

People don’t like silence and they will talk to fill it. The more people talk, you the more you learn about them, their thoughts and their ideas.

Less is more

”The human tongue is a beast that few can master. It strains constantly to break out of its cage, and if it is not tamed, it will run wild and cause you grief.” Robert Greene

Speaking less reduces your chances of saying something stupid or saying things which are incorrect. speaking more, increases the chances of you saying something stupid or something you will regret.

Time to think

The less you speak, the more time you have to think. You can’t talk and think, you can’t listen and think. When you listen you gather information, when the speaker stops, you think about the new data and how it fits with the existing data you had.

Ask questions

When you ask questions, you get answers. If you disagree, you can ask a question and highlights the weakness in their ideas. Don’t tell people they are wrong, ask questions and help them change their own minds.

Changing minds

Time arguing is time wasted and unsuccessful. So do less of it and focus on being positive. Don’t waste time on negativity.

Getting requirements

A mistake people make when getting requirements is stop listening and move to creating the solution. They stopped listening they didn’t create the solution that user needed because they didn’t understand the requirement.


Listen more than you speak, focus on acquiring information rather than sharing it. You gain little less by talking and more from listening. 

The more you talk, the more you give away. Listen, learn and follow Robert Greene’s 4th Law — always say less than necessary