Dynamics 365 – Understanding The Teams Member Licence Restrictions

July 22, 2021July 22, 2021Hosk4 Comments

The art of simplicity is a puzzle of complexity.
Douglas Horton

The story of Team Member licence

The Team member licence has had a roller coaster ride with Dynamics 365. As soon as Microsoft released the generous first Team Member licence they realised they had made a mistake because it let users too do much.

This lead to a stampede of users buying team member licences and with no enforcement it was happy days and business saved themselves money on licences.

Microsoft quickly plugged the dam and updated the Teams Member licence to be more restrictive (but not enforced technically yet). This caused a lot of complaining because Microsoft had given a child an ice cream with their right hand and took it back instantly with the left hand.

Dynamics 365 now technically enforces the Team Member licence limitations, which will have caused lots of users to have to upgrade their licences to full licences’.

Just like when a developer gives an estimate, it’s never forgotten (unless it goes down) and there are still people out there who think the Teams Member licence is cheap and great. It’s cheap and so limited few can use it.

Team licences are not the only choice

The licencing choices are not full licence or teams, there are other options that can meet your needs.

Create an internal portal
Create a canvas app

The key is to split down the team licence users into smaller groups and you can create smaller options.

Not all problems need a Dynamics 365 solution, see if Power Apps can offer a solution, licences are much cheaper.

Team member highlights

If there is any document more ambiguous than a Microsoft licencing guide I am yet to find it. Microsoft are master at creating ambiguous wording so even Microsoft employees can’t give a definitive answer. Interpretation of Microsoft Dynamics 365 Licensing Guide is a bit like looking at abstract art, everyone sees something different.

The teams member licence which was originally quite generous and enforced by a trust policy (e.g. if they audit you and catch you, you get told off)

This is my interpretation and it could be wrong because it’s not straightforward, so please read the full documents.

Teams licence can only use the Microsoft specified Dynamics 365 applications
You can update and configure the teams licence apps
Teams licence restrictions is enforced with code and is no longer trust based
Team members can view all the Dynamics 365 data entities
Addition to the 15 entities that can be added directly to each Team Member app and full crud
The 15 entities have to be related to Sales and customer service processes (this isn’t technically implementable but a spirit of the licence approach)

This blog New Team Member apps for Dynamics 365 by Jukka breaks down the team member limitations so it’s easy to understand.

Detailed information and sources

I copied the key pieces of information from Microsoft’s online documents and licencing guide. I have done this because I just want the highlights and not get lost in the licencing guide and document pages again.

This Microsoft page has a simple overview — Dynamics 365 Team Members license,

Teams licence can only use the three out of the box Dynamics 365 app
· Customer Service Team Member
· Sales Team Member
· Project Resource Hub
Will Team Member users be able to access custom model-driven applications in the organization?
After enforcement is applied for your environment (organization instance), users with the Team Member license will only be able to access Team Member applications.
I need my users to access a custom app. What’s the best license to assign for these users?
For accessing custom apps, users need to be assigned a Power Apps per-app license or per-user license, as appropriate. If the user needs access to one or two apps, consider the per-app license as an option; otherwise, the user will need the per-user option, which allows access to unlimited custom apps on the platform. For more information, see the Power Apps home page, and Dynamics 365 Pricing.

Microsoft licencing guide highlights

If there is any document more ambiguous than a Microsoft licencing guide I am yet to find it😊

Microsoft Dynamics 365 Licensing Guide

Team Members license: This license, also assigned to a named user, is for users who are not tied to a particular function but require read-only access to all data and basic Dynamics 365 functionality for designated scenarios such as expense entry or updating contacts.
Users with a Team Members license can read Dynamics 365 data generated from Finance, Supply Chain Management, Commerce, Human Resources, Project Operations, Sales, Customer Service, and Field Service. They may access a specific set of the functionalities of these products. The Team Members license does not provide access to custom applications. You have limited table (formerly known as ‘entity’) customization options for Team Members, read more about custom tables in Appendix D.
Key part from Appendix D
Team Members
1. Create and modify up to 15 additional tables (custom tables or standard Dataverse tables) per Team Members application module.
2. All customization must be per pre-approved scenarios in Appendix C.
3. No limit on read rights for Dynamics 365 custom tables
4. Full CRUD on data records associated with custom tables
You can add up to 15 tables (standard and/or custom) per Team Members application module. If you want to view (read only) more than 15 tables, you can do so by creating dashboards and sub-grids. See more information on Team Members license documentation.

Sales team member app

Team member licences only work with team member apps, lets understand a bit more about those apps from the licencing guide

Only employee self-serve: customer management — work with contacts or read accounts; lead and opportunity management — read leads and opportunities linked with accounts (Sales for Team Members, Portal1 or API access only)

Microsoft documentation — Sales Team Member app for users with Team Member license

At a high level, users with the Team Member license can perform the following tasks in the Sales Team Member app:
· Customer management: work with contacts or see accounts.
· Lead and opportunity management: see leads or opportunities linked with accounts or contacts, or see other sales-related data.
· Add notes and activities, such as tasks.

Looking at the Sales Team Member indicates how restrictive it is, there is nothing in it apart from Accounts, Contacts, Leads, Opportunities and Activities.

Original blog post on medium – Understanding the Dynamics 365 Teams Member Licence Restrictions

Why is low code software development and Power Apps exploding?

June 16, 2021June 16, 2021Hosk1 Comment

The ability to deliver software fast and by citizen developers is changing the software development world

Photo by Porapak Apichodilok from Pexels

Low code is eating the world, developers have a choice joining the feast or getting eaten

Low code developer is like YouTube to television or twitter to blog posts. It’s growing fast because you can create solutions without code and deploy to production in days. This type of functionality needed multiple developers and weeks of development, particularly with integrations.

Low code is exploding and leading to a Hyper Growth and taking big bites out of traditional software development. There is the question Will low code software reduce the burden for IT teams or increase it? and some people think it could be the end of developers and code (spoiler alert it won’t) Why Low-Code Development will not be the end of developers or code

A forecast from Gartner Inc says low-code development will grow nearly 23% this year, to $13.8 billion and hit $17 billion in 2022

This article states

“The global low-code development platform market size is projected to grow from USD 13.2 billion in 2020 to USD 45.5 billion by 2025, at a Compound Annual Growth Rate (CAGR) of 28.1% during the forecast period”

First seeing Microsoft Dynamics CRM 4

I was once a C# developer, there was plumbing code to be written before you could write the business logic code. Setting up databases, setting up security roles, create buttons on pages, lots of code that was needed before I could write the business logic.

One day someone showed Microsoft Dynamics CRM 4, which was not great and really a collection of Microsoft products (SQL database, Microsoft Active directory, ISS, Exchange) mashed together with a framework for creating customisations (code and workflows).

What I saw CRM it did much of the plumbing and had GUI tools to create forms, add tables and fields to database. It used Microsoft active directory for security. You could setup the framework of a system quickly and focus on creating the solution to meet business requirements.

As soon as I saw Microsoft Dynamics CRM 4, I stopped being a C# developer and starting working with Microsoft Dynamics.

The Power Platform low code approach could have the same effect Dynamics had on previous software development and grow massively in the next 5 years.

There are other low code development platforms but I will stick to what I know what talk about Microsoft’s Power Platform.

Low code disruption

I’m using Microsoft Power Platform as the example but there are other similar low code platforms.

Service

Low code solutions and Dataverse/Dynamics are services where you pay for licences and consumption. The removes the cost of hosting servers and the need to hire technical experts to maintain the servers. Maintenance includes upgrading, disaster recovery and performance. Developers can focus on creating solutions and Microsoft takes care of the environments.

No Code

Power Platform doesn’t need developer to write code. Power Apps use drag-and-drop components to create user interfaces, which work on a browser and mobile device. More people can learn to create solutions using low code platforms and this reduces costs because you don’t need to pay developer wages.

Integrations

One difficulty in creating software is integrating separate systems together. Microsoft has hundred of connectors which connect two systems together without code. There are over 300 connectors (here is a list) connecting your Power Apps and Power Automates

Twitter
Azure DevOps
SharePoint
Outlook
Docusign/Adobe Sign
MailChimp
ServiceNow
Power BI
Salesforce
Twilio

You can create custom connectors, once created they can then be used by the low code developers.

Speed

Dynamics 365 and CRM frameworks disrupted Software development by linking common functionality together and allowed sped up development. All companies wanted accounts, contacts, activities and many wanted core sales (leads, opportunities, invoices) or Marketing etc. It simplified security, service and allowed customer to use their existing expenditure with Microsoft products (Office, Active directory, etc)

Dynamics 365 accelerated development but often resulted in larger projects because you needed to justify the licence costs.

Big projects are expensive and have a big upfront cost before you see any return on investment.

Low code gives an almost instant return on the investment of creating the solution.

Empowering the non coders

Low code software allows applications to be made quickly and with some upskilling the customer has the possibility of taking ownership of the low code solutions and creating their own.

Microsoft sells the skills needed as advanced Excel formula skills, learning to create Power Apps and Power Automates can created by a bigger pool of people and don’t need to be developers.

The sale pitch of citizen developers ignores the professionalism of developers is not in their ability to write code but in the steps and approach they bring, which makes maintaining, deploying, testing easier. The quality steps developers do is to minimise complexity and ease maintenance and extension of the applications. Creation can take days or weeks, but maintaining you maintain the solutions for years. The cost of maintenance is brushed under the carpet because it ruins the low code dream.

Conclusion

Low code development is nimble and enables quick creation and deployment of solutions. The return on investment is faster than traditional IT projects and the initial cost is smaller.

The speed Low code applications can be deployed into production means they an instant impact and they are significantly cheaper than the alternatives. The costs for companies who already have Microsoft office makes it a cost effective choice and the costs are licence and consumption based, which means there is little upfront costs.

The move to Power Platform and low code development will create many smaller solutions rather than one large solution. This increases the maintenance overhead, which needs to be maintained and upgraded twice a year. Will low code solution hit problems at scale?, how easy will it be to support hundreds or thousands of small applications?

I can hear the IT support desks already complaining at the thought of this. This part of the puzzle is yet to hit real world realities of support because non developers are busy creating lots of low code applications.

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.

Why IT projects are underestimated
How we try to speed up IT projects and why it doesn’t work — Reducing quality slows down codes journey to production
Creating software is the start not the end — explains that creating software is a misleading because the cost of software is in the maintenance.
Software development is a loser’s game — Software development should focus on reducing bugs and finding them in dev.
Why adding more people to a project doesn’t make it go faster — every person increases communication and makes collaboration harder.

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

April 29, 2021April 29, 2021HoskLeave a comment

“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.

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

March 29, 2021March 29, 2021Hosk1 Comment

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.

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.

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

Relationship with the customer
Scope growing out of control
Missing requirements
Impossible deadlines
Low standards
poor leadership
technical limitations

Company — Dynamics partner

reduced sales
High churn rate/people leaving
Poor leadership/lack of engagement
No strategy to win
Behind the technology curve

Solution architect

Missing non function requirements
A solution that doesn’t work
A solution not scalable
Bottle necks
Uncontrolled scope
Your knowledge not keeping track with technical change

Developer

The project leadership
poor estimates
Technical debt
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

March 22, 2021March 22, 2021Hosk1 Comment

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

The story of Team Member licence

Team licences are not the only choice

Team member highlights

Detailed information and sources

Microsoft licencing guide highlights

Sales team member app

Share this:

First seeing Microsoft Dynamics CRM 4

Low code disruption

Service

No Code

Speed

Empowering the non coders

Conclusion

Other articles to read

Share this:

Why are they wrong?

What really happens

What’s the problem

Conclusion

Share this:

Why is development hard?

The cost of learning

Why is experience valuable

Conclusion

Other articles you might like

Share this:

Slow death

Dynamics on premise versus Dynamics 365 online

No code revolution

Survival of the fittest

Stay curious

Interesting articles

Share this:

Development can be torturous

Positive attitude

Other articles you might like

Share this:

Evolution

First principles

First principles with Dynamics 365 development

Business first not technology

Other articles you might like

Share this:

Why is development hard?

The cost of learning

Why is experience valuable

Conclusion

Other articles you might like

Share this:

The Fifth Risk

Example

People don’t see them coming

Covid-19 — Coronavirus

The fifth risk in different areas

Projects

Company — Dynamics partner

Solution architect

Developer

Conclusion

Share this:

Admit you don’t know

Circle of competence

Overruling experts

We all have a few tricks

Playing and managing

Conclusion

Interesting articles

Share this: