Is Change Management a Myth or a Possibility

The theory that it is possible to manage organisational change (Change Management) in a particular direction has done the rounds for quite some time, but is it true about Change Management. Was Barrack Obama correct when he said, ?Change will not come if we wait for some other person or some other time. We are the ones we have been waiting for. We are the change that we seek.?
Or, was business coach Kelly A Morgan more on the button when she commented, ?Changes are inevitable and not always controllable. What can be controlled is how you manage, react to, and work through the change process.? Let us consult the evidence and see what statisticians say.

What the Melcrum Report Tells Us

Melcrum are ?internal communication specialists who work alongside leaders and teams around the globe to build skills and best practice in internal communication.? They published a report after researching over 1,000 companies that attempted change management and advised:

? More than 50% report improved customer satisfaction

? 33% report higher productivity

? 28% report improvements in employee advocacy

? 27% improved status as a great place to work

? 27% report increased profitability

? 25% report improved absenteeism

Sounds great until we flip the mirror around and consider what the majority apparently said:

? 50% had no improvement in customer service

? 67% did not report increased productivity

? 72% did not note improvements in employee advocacy

? 73% had no improved status among job seekers

? 73% did not report increased profitability

? 75% did not report any reduction of employee absenteeism

This shows it is still a great idea to hear what all parties have to say before reaching a conclusion. You may be interested to know the Melcrum report gave rise to the legend that 70% of organisation change initiatives fail. This finding has repeated numerous times. Let’s hear what the psychologists have to say next.

There is a certain amount of truth in the old adage that says, ?You can lead a horse to water but you cannot make him drink.? Which of us has not said, ?Another flavour of the week ? better keep heads down until it passes? during a spell in the corporate world. You cannot change an organisation, but you can change an individual.

At the height of the Nazi occupation of 1942, French philosopher-writer Antoine de Saint-Exup?ry said, ?A rock pile ceases to be a rock pile the moment a single man contemplates it, bearing within him the image of a cathedral?. Psychology Today suggests five false assumptions change management rests upon, THAT ARE SIMPLY NOT TRUE.

1. The external world is orderly, stable, predictable and can be managed

2. Change managers are objective, and do not import their personal bias

3. The world is static and orderly and can be changed in linear steps

4. There is a neutral starting point where we can gather all participants

5. Change is worthy in itself, because all change is an improvement

Leo Tolstoy wrote, ?Everyone thinks of changing the world, but no one thinks of changing himself.? A prophet can work no miracles unless the people believe. From the foregoing, it is evident that change management of an organisation is a 70% impossibility, but encouraging an individual to grow is another matter.

A McKinsey Report titled Change Leader, Change Thyself fingers unbelieving managers as the most effective stumbling stones to change management. To change as individuals ? and perhaps collectively change as organisations ? we need to ?come to our own full richness?, and as shepherds lead our flock to their ?promised land?, whatever that may be. Conversely, herding our flock with a pack of sheepdogs extinguishes that most precious thing of all, human inspiration.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Check our similar posts

5 Ways To Grow Your Business | How Field Service Management Software Helps

Building up any business is already hard, more so when it involves providing field services.

A field service business owner has to manage the usual tasks, like scheduling jobs efficiently or inventory checks, and you have to do it while your employees are scattered about on various locations.

It’s the reason FieldElite was created, to provide companies with a much better way to manage and monitor their field workers.

Aside from effective management for your workforce on the move, field service management software can also help your business grow.

5 Ways Using Field Service Management Software Grows Your Business

1. Management Integration

You replace manual field service processes. If your business also uses other management apps, like CRM, payroll, industry-specific software, etc., make sure to integrate them with your chosen field service management software.?

Make those software work side-by-side with your field service management app to achieve streamlined business management.

Integration also removes the possibility of duplicate input on the regular system used and your field service management software, maximising your efficiency and business growth.

2. Improved Tracking

Utilising a field service management software gives you better tracking of every aspect of your field service business.

  • Track your inventory numbers in real-time ? know exactly how much stock is on hand for parts, and when it’s time to order more
  • Constant updates on Key Performance Indicators ? ensure your business is running smoothly
  • First-time fix rates tracking ? avoid wrong rate application
  • Monitor your technician?s performance ? ensuring quality work, in turn, profit.

Grow your business by having improved tracking on meaningful data and analytics produced from your field service management software.

3. Cost Cutting

Cutting costs can improve your bottom line and a lot of businesses turn to laying off technicians to cut costs. With a field service management software, there?s no need to go this route.

You cut costs through no manual processes needing to be completed. No need to hire back-office staff to field service calls or produce paperwork orders.

Your field service software should have all your automated needs met for efficient field job management.

An example of cost-cutting using field service app:

Track how much your technicians drive and find alternate routes for them to take.

  • Reduce gas expenses
  • Reduce repair bills for the truck
  • Finding better alternate routes can give more time to get to more jobs
  • Increased efficiency for the field technician

4.? Mobile Adaptability

Field service companies are focusing on mobility to grow their business. With a field service management software, technicians have on hand the tools and information needed to complete their job.

Field technicians can utilise the following field service software features:

  • Limit how much time they spend completing administrative work with the automated work-order management
  • Complete checklists on their mobile device and follow step-by-step instructions
  • Check service history
  • Close job orders/calls, collect signatures and start the invoice process

With a mobile app, technicians can complete a call faster, increasing the number of job order scheduled each day, giving additional revenue and that helps to grow your business.

5. Automation

What good is a field service management software without automated features??

Automation, in any industry, is an important factor in managing and growing your business.

Here are some examples of automation features and tools that your software needs in field service:

  • Create and convert quotations into work orders
  • Schedule/Reschedule jobs
  • Accept jobs in the field
  • Convert jobs into invoices
  • Preventative maintenance service
  • Customer updates
  • Automated job reports

Business Growth with your Field Service Management Software

Field service management software is growing businesses through automation, tracking and workflow management.

Your operation can run smarter and more efficiently, all while empowering your field technicians to do their job smoothly.

If you haven’t turned to a field service management software yet, you’re missing out on chances to grow your business.

Check out FieldElite to help grow your field service business today!

How To Get Started with your IT Compliance Efforts for SOX

There’s no question about it. For many of you top executives in the corporate world, all roads leading to a brighter future have to go through SOX compliance. And because the business processes that contribute to financial reporting (the crux of the Sarbanes-Oxley Act) are now highly reliant on IT systems, it is important to focus a good part of your attention there.

It is a long and arduous path to IT compliance, so if you don’t want your company to fall by the wayside due to inefficient utilisation of resources, it is important to set out with a plan on hand. What we have here are some vital information that will guide you in putting together a sound plan for SOX compliance of your company?s IT systems.

Why focus on IT systems for SOX compliance?

We’ll get to that. But first, let’s take up the specific portions of the Sarbanes-Oxley Act that affect information technology. These portions can be found in Section 302 and Section 404 of the act.

In simplified form, Section 302 grants the SEC (Securities and Exchange Commission) authority to come up with rules requiring you, CEOs and CFOs, to certify in each annual or quarterly financial report the following:

  • that you have reviewed the report;
  • that based on your knowledge, the report does not contain anything or leave out anything that would render it misleading;
  • that based on your knowledge, all financial information in the report fairly represent the financial conditions of the company;
  • that you are responsible for establishing internal controls over financial reporting; and
  • that you have assessed the effectiveness of the internal controls.

Similarly, Section 404, stated in simplified form, allows the SEC to come up with rules requiring you, CEOs and CFOs, to add an internal control report to each annual financial report stating that you are responsible for establishing internal controls over financial reporting.

You are also required to assess the effectiveness of those controls and to have a public accounting firm to attest to your assessment based upon standards adopted by the Public Company Accounting Oversight Board (PCAOB).

While there is no mention of IT systems, IT systems now play a significant role in financial reporting. Practically all of the data you need for your financial reports are stored, retrieved and processed on IT systems, so you really have to include them in your SOX compliance initiatives and establish controls on them.

Now that that’s settled, your next question could very well be: How do you know what controls to install and whether those controls are already sufficient to achieve compliance?

Finding a suitable guide for IT compliance

The two bodies responsible for setting rules and standards dealing with SOX, SEC and PCAOB, point to a well-established control framework for guidance – COSO. This framework was drafted by the Committee of Sponsoring Organisations of the Treadway Commission (COSO) and is the most widely accepted control framework in the business world.

However, while COSO is a tested and proven framework, it is more suitable for general controls. What we recommend is a widely-used control framework that aligns well with COSO but also caters to the more technical features and issues that come with IT systems.

Taking into consideration those qualifiers, we recommend COBIT. COBIT features a well thought out collection of IT-related control objectives grouped into four domains: Plan and Organise (PO), Acquire and Implement (AI), Deliver and Support (DS), and Monitor and Evaluate (ME). The document also includes maturity models, performance goals and metrics, and activity goals.

A few examples of COBIt’s detailed control objectives are:

DS4.2 – IT Continuity Plans
DS4.9 – Offsite Backup Storage
DS5.4 – User Account Management
DS5.8 – Cryptographic Key Management
DS5.10 – Network Security
DS5.11 – Exchange of Sensitive Data

By those titles alone, you can see that the framework is specifically designed for IT. But the document is quite extensive and, chances are, you won’t need all of the items detailed there. Furthermore, don’t expect COBIT to specify a control solution controls for every control objective. For example, throughout the control objective DS4 (Ensure Continuous Service), you won’t find any mention of virtualisation, which is common in any modern business continuity solution.

Basically, COBIT will tell you what you need to attain in order to achieve effective governance, management and control, but you’ll have to pick the solution best suited to reach that level of attainment.

Articles highly relevant to the one you just read:

Month End Accounting The Way It Should Be Today
Spreadsheet Woes ? Burden in SOX Compliance and Other Regulations
Spreadsheet Woes ? Limited Features For Easy Adoption of a Control Framework
How Internal Auditors Can Win The War Against Spreadsheet Fraud

What Is Technical Debt? A Complete Guide

You buy the latest iPhone on credit. Turn to fast car loan services to get yourself those wheels you’ve been eyeing for a while. Take out a mortgage to realise your dream of being a homeowner. Regardless of the motive, the common denominator is going into financial debt to achieve something today, and pay it off in future, with interest. The final cost will be higher than the loan value that you took out in the first place. However, debt is not limited to the financial world.

Technical Debt Definition

Technical debt – which is also referred to as code debt, design debt or tech debt – is the result of the development team taking shortcuts in the code to release a product today, which will need to be fixed later on. The quality of the code takes a backseat to issues like market forces, such as when there’s pressure to get a product out there to beat a deadline, front-run the competition, or even calm jittery consumers. Creating perfect code would take time, so the team opts for a compromised version, which they will come back later to resolve. It’s basically using a speedy temporary fix instead of waiting for a more comprehensive solution whose development would be slower.

How rampant is it? 25% of the development time in large software organisations is actually spent dealing with tech debt, according to a multiple case study of 15 organizations. “Large” here means organizations with over 250 employees. It is estimated that global technical debt will cost companies $4 trillion by 2024.

Is there interest on technical debt?

When you take out a mortgage or service a car loan, the longer that it takes to clear it the higher the interest will be. A similar case applies to technical debt. In the rush to release the software, it comes with problems like bugs in the code, incompatibility with some applications that would need it, absent documentation, and other issues that pop up over time. This will affect the usability of the product, slow down operations – and even grind systems to a halt, costing your business. Here’s the catch: just like the financial loan, the longer that one takes before resolving the issues with rushed software, the greater the problems will pile up, and more it will take to rectify and implement changes. This additional rework that will be required in future is the interest on the technical debt.

Reasons For Getting Into Technical Debt

In the financial world, there are good and bad reasons for getting into debt. Taking a loan to boost your business cashflow or buy that piece of land where you will build your home – these are understandable. Buying an expensive umbrella on credit because ‘it will go with your outfit‘ won’t win you an award for prudent financial management. This also applies to technical debt.

There are situations where product delivery takes precedence over having completely clean code, such as for start-ups that need their operations to keep running for the brand to remain relevant, a fintech app that consumers rely on daily, or situations where user feedback is needed for modifications to be made to the software early. On the other hand, incurring technical debt because the design team chooses to focus on other products that are more interesting, thus neglecting the software and only releasing a “just-usable” version will be a bad reason.

Some of the common reasons for technical debt include:

  • Inadequate project definition at the start – Where failing to accurately define product requirements up-front leads to software development that will need to be reworked later
  • Business pressure – Here the business is under pressure to release a product, such as an app or upgrade quickly before the required changes to the code are completed.
  • Lacking a test suite – Without the environment to exhaustively check for bugs and apply fixes before the public release of a product, more resources will be required later to resolve them as they arise.
  • Poor collaboration – From inadequate communication amongst the different product development teams and across the business hierarchy, to junior developers not being mentored properly, these will contribute to technical debt with the products that are released.
  • Lack of documentation – Have you launched code without its supporting documentation? This is a debt that will need to be fulfilled.
  • Parallel development – This is seen when working on different sections of a product in isolation which will, later on, need to be merged into a single source. The greater the extent of modification on an individual branch – especially when it affects its compatibility with the rest of the code, the higher the technical debt.
  • Skipping industrial standards – If you fail to adhere to industry-standard features and technologies when developing the product, there will be technical debt because you will eventually need to rework the product to align with them for it to continue being relevant.
  • Last-minute product changes – Incorporating changes that hadn’t been planned for just before its release will affect the future development of the product due to the checks, documentation and modifications that will be required later on

Types of Technical Debt

There are various types of technical debt, and this will largely depend on how you look at it.

  • Intentional technical debt – which is the debt that is consciously taken on as a strategy in the business operations.
  • Unintentional technical debt – where the debt is non-strategic, usually the consequences of a poor job being done.

This is further expounded in the Technical Debt Quadrant” put forth by Martin Fowler, which attempts to categorise it based on the context and intent:

Technical Debt Quadrant

Source: MartinFowler.com

Final thoughts

Technical debt is common, and not inherently bad. Just like financial debt, it will depend on the purpose that it has been taken up, and plans to clear it. Start-ups battling with pressure to launch their products and get ahead, software companies that have cut-throat competition to deliver fast – development teams usually find themselves having to take on technical debt instead of waiting to launch the products later. In fact, nearly all of the software products in use today have some sort of technical debt.

But no one likes being in debt. Actually, technical staff often find themselves clashing with business executives as they try to emphasise the implications involved when pushing for product launch before the code is completely ready. From a business perspective, it’s all about weighing the trade-offs, when factoring in aspects such as the aspects market situation, competition and consumer needs. So, is technical debt good or bad? It will depend on the context. Look at it this way: just like financial debt, it is not a problem as long as it is manageable. When you exceed your limits and allow the debt to spiral out of control, it can grind your operations to a halt, with the ripple effects cascading through your business.

 

Ready to work with Denizon?

Contact Us Today