Sunday, 21 December 2014

Machine to Machine (M2M) Operational Efficiency

Operational Efficiency:

M2M enables customers to save time and money by optimising business processes. Cost saving remains one of the primary drivers for businesses to adopt M2M solutions today as the recovery of one misplaced diesel generator, for example, can cover the installation and running costs of an M2M tracking solution.

Here are some of the ways our customers are optimising their business with our M2M solutions:
  • Remote monitoring and analytics reduce the cost of failure, minimise the need for ‘routine maintenance’ visits and problems can be fixed before they have an impact on the customer.
  • Accurate information is delivered in real time, enabling quicker business decisions, less machine down-time and better production yield.
  • Information can be collected automatically and systems maintained and repaired remotely so engineers and service staff can manage their time more effectively.
  • Asset tracking enables theft recovery, theft prevention, status monitoring and inventory.
  • Vodafone has saved at least £2 million annually on its UK energy bills through automated monitoring of energy consumption at its base stations with Bglobal.

Embedded connectivity enables you to accelerate time to market for a wide range of connected M2M applications such as:
  • Remote monitoring and control - remote monitoring of machines and devices (air conditioning systems, compressors, pumps, gas engines).
  • Financial Services - ATM and other financial applications.
  • Public safety and public transport systems.
  • M2M SIM card already inserted for quick and easy start-up.
  • Health - Medical and industrial applications.
  • Business Continuity - Primary and back-up wireless connections for near 100% up-time.
  • Consumer Goods - Rapidly deployable wireless payment solutions.
  • Digital Signage - Eliminate landlines and reach your customers in more locations.
  • Small Office - affordable and reliable 2G and 3G connections for small and temporary offices.
  • Security/Surveillance - connect IP surveillance cameras over mobile broadband.
  • Energy and Utilities - monitor and control remote industrial equipment.

Asset Tracking:

Efficiently managing critical business assets such as tools, supplies, equipment, fleet or products poses a significant challenge and can be a highly labour-intensive and costly process. Additionally, the theft, loss, breakdown or delay in delivery of assets can have huge financial implications - loss of working time, delays in production, the expense of hiring in alternative equipment and increased insurance premiums.
With increasing competition demanding greater flexibility and process efficiency, the inability to track and recover assets due to poor process controls and lack of automation can have a significant impact. Businesses need to look at how they can do more with less – how they can automate manual processes, increase efficiencies, reduce theft and loss and optimise uptime and utilisation of assets.

Saturday, 22 November 2014

Business Rule Manifesto

The Business Rules Manifesto*

Article 1.Primary Requirements, Not Secondary


Rules are a first-class citizen of the requirements world.


Rules are essential for, and a discrete part of, business models and technology models.
Article 2.Separate From Processes, Not Contained In Them


Rules are explicit constraints on behavior and/or provide support to behavior.


Rules are not process and not procedure.  They should not be contained in either of these.


Rules apply across processes and procedures.  There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.
Article 3.Deliberate Knowledge, Not A By-Product


Rules build on facts, and facts build on concepts as expressed by terms.


Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.


Rules must be explicit.  No rule is ever assumed about any concept or fact.


Rules are basic to what the business knows about itself -- that is, to basic business knowledge.


Rules need to be nurtured, protected, and managed.
Article 4.Declarative, Not Procedural


Rules should be expressed declaratively in natural-language sentences for the business audience.


If something cannot be expressed, then it is not a rule.


A set of statements is declarative only if the set has no implicit sequencing.


Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.


A rule is distinct from any enforcement defined for it.  A rule and its enforcement are separate concerns.


Rules should be defined independently of responsibility for the whowherewhen, or how of their enforcement.


Exceptions to rules are expressed by other rules.
Article 5.Well-Formed Expression, Not Ad Hoc


Business rules should be expressed in such a way that they can be validated for correctness by business people.


Business rules should be expressed in such a way that they can be verified against each other for consistency.


Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.
Article 6.Rule-Based Architecture, Not Indirect Implementation


A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.


Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.


A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.


Rules are based on truth values.  How a rule’s truth value is determined or maintained is hidden from users.


The relationship between events and rules is generally many-to-many.
Article 7.Rule-Guided Processes, Not Exception-Based Programming


Rules define the boundary between acceptable and unacceptable business activity.


Rules often require special or selective handling of detected violations.  Such rule violation activity is activity like any other activity.


To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.
Article 8.For the Sake of the Business, Not Technology


Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.


Rules always cost the business something.


The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.


‘More rules’ is not better.  Usually fewer ‘good rules’ is better.


An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.
Article 9.Of, By, and For Business People, Not IT People


Rules should arise from knowledgeable business people.


Business people should have tools available to help them formulate, validate, and manage rules.


Business people should have tools available to help them verify business rules against each other for consistency.
Article 10.Managing Business Logic, Not Hardware/Software Platforms


Business rules are a vital business asset.


In the long run, rules are more important to the business than hardware/software platforms.


Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.


Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003.  Edited by Ronald G. Ross.

Friday, 20 June 2014

Measuring Progress

Measurement is not only important in my business process improvement, but it is also again and again important in improving the human condition, making a difference and determining which approaches work and which do not.

You can achieve amazing progress if you set a clear goal and find measurement that will drive progress towards that goal-in a feedback loop to drive best approaches that work.

It is outstanding to see in the video that Bill Gates talks about his foundation great work and how measurement is used to justify progress.

Thanks to cell phones, satellites and cheap sensors, we can gather and organise data with increasing speed and accuracy.

Monday, 9 June 2014

Business Analysis scope

I am often asked how to best go about a particular business analysis scenario; how to do a particular technique. Usually the person is asking more than just best practices, but looking for a short-cut or one-size-fits-all process to go about doing business analysis. I hate to break it to you…there is no such thing.
What I often find in the question is that the person is getting hung up on the process or technique and has lost sight of the ultimate goal…which should always be to add business value. So in attempt to answer the question for all business analysis scenarios and professionals, I will give you my personal operating goals when conducting business.
Remember business analysis is not just the IT Business Analyst or Business Systems Analyst that works on IT projects to deliver software solutions to the business. Whether you are an IT Business Analyst, Enterprise Architect, Process Improvement Analyst, Data Analyst or one of the other business analysis roles, you have to interact with and build relationships with stakeholders and your ultimate goal should be to deliver business value to those stakeholders. So these operating goals relate to you.


There are many areas of business analysis that cover many strategic, tactical and operational roles within the organization. There are 34 techniques defined in the Guide to the Business Analysis Body of Knowledge® (BABOK®) version 2.0. With that kind of breadth of coverage it would be impossible to have one simple way to do things. Even in a requirements elicitation activity, what worked last time, with that set of stakeholders, may not work this time with this set of stakeholders. Experience is the best teacher. Go into each activity prepared, ready to do your best and flexible enough to handle the different alternatives that can be thrown your way.


The best way to be proactive is to plan ahead. If you are working with a new line of business or business process that you are unfamiliar with, learn as much about it as possible before you engage in your business analysis activities. There are many techniques that the Business Analyst can use to learn about a business process on his/her own.


Never go into an elicitation activity cold, be prepared to facilitate the discussion; but realize that the Business Analyst’s job is not to direct the conversation to a preconceived end, but guide the conversation to ensure that it is productive. You may walk into the activity with a preconceived idea of the way the conversation may go, but don’t mistakenly think that is the only way the conversation can go. When the conversation takes an unexpected turn away from your preconceived idea don’t attempt to stop it, allow it to develop and see where it may lead and what can be learned from it. Guiding the conversation means making sure side conversations are kept to a minimum and that everyone’s voice gets heard. You should never walk into a facilitation activity with the goal of forcing all stakeholders to agree on a particular point. It is alright to walk in with the goal of trying to get buy-in or consensus on a point, but if you do not get that consensus that is not necessarily failure.


Your requirements, process model or design does not have to be perfectly written before you share it with the stakeholders with which you are working. Building these things in collaboration with the stakeholders usually produces better results. Remember that the business stakeholders and project team members that you are working with are not perfect either. They may not articulate everything just perfect or give you perfect feedback on your requirements or models. Seasoned professionals will work through these difficulties.


As I just mentioned working collaboratively with your stakeholders usually produce better results. The days of the Business Analyst conducting elicitation activities, running off to write the requirements by themselves and then presenting them back to the stakeholders is quickly coming to an end. When possible, write the requirements, or build the process model, during the elicitation activity. Spend the time with the stakeholder and work together to produce the requirements or design. The good by-product of this method is a much easier signoff of the requirements or design.


You are not perfect. The people you work with are not perfect. Don’t think that everything you do will be perfect or end in success. It was Colin Powell that said “There are no secrets to success. It is a result of preparation, hard work and learning from failures.” Failure is not a failure if you learn from it. When something doesn’t go as expected, take a moment to reflect upon the activity and your role in it. What could you have done better.


No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, you can learn from others on the teams on which you work. Everybody in the organization may look to you as the subject matter expert (SME) in business analysis, but that doesn’t mean you can’t learn. If you are open to it, you may be able to learn from that Business Analyst that the company just hired last week. Look at the way other team members operate, what they do good and what they do bad. Incorporate the good into the way you operate. Also remember, you can learn from others doing activities outside of the business analysis space.


I have seen business analysts get so caught up on the particular activity or technique that they are doing that they forget why they are doing it. They may be trying to be so perfect that they lose sight of the goal. The Business Analyst’s ultimate goal should be to add business value, but they should know the goal of each activity that they undertake. Now that you keep the goal in mind, determine the “why”. When investigating a new area or business process, get to the “why”. Why do the people do it that way. What is the business value of doing it that way. I have heard it said to ask “why” five times (The 5 why’s). It may not need 5 times, but asking “why” multiple times is a good process to get to the underlying root cause.


The goal of your business analysis activities should be to add business value. The goal for you in the Business Analyst role within the organization should be to become the trusted advisor. You have to build relationships with all the stakeholders in the organization from your technical team members, project managers, business stakeholders, IT management and business management to build the trust so that these stakeholders will give more weight to your recommendations. When your business stakeholders see you accurately representing their points of view, when IT and business management see you working for the best interest of the organization and working to add business value, trust will grow and you will find your work easier to perform built on that trust.


No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, learn from others and learn from past challenges and successes. Not only work to become the trusted advisor to everyone in the organization and to add business value; but work to hone your own craft. If you think that you’re so good that there is nothing more for you to learn, I would say to you “get over yourself”. The business analysis space is changing dramatically and will continue to over the coming years. There are new and better ways of doing things being discovered all the time. If you are not consistently working on improving the way you do business analysis then you are standing still and the world, and your organization, will grow beyond you. So continually look for ways to improve your own processes.
As you can see there is a lot to business analysis, inside and outside of software development projects. The Business Analyst cannot stand still in their way of doing things. The business analysis profession, the business environment and your organization are continually changing and growing. The only constant in the universe is change. The Business Analyst professional must change also. Grow in your understanding of business processes, your profession, your organization and the environment in which it operates. Stay up on the latest trends and look for ways to incorporate the way you do your business analysis activities.

Monday, 26 May 2014

Change and Realse Management

I was recently challenged by an organisation to answer a simple question: what is the purpose of change and release management is in ITIL or any other IT best practice framework?

Change is not about doing the change, and release is not about managing the approval of a request to change. Change helps me make a decision; it answers the question WHY with a “yes” or “no”. But “yes” or “no” to what?

How many times has a request been approved, but what was delivered did not match what was approved? If IT has no value until it releases something that is usable to a customer, we better be sure that “yes” and “approved” are used for getting an organisation to be competitive, compliant, reliable, secure and cost-efficient as quickly as possible. Lean helps by creating a value stream from idea to solution, in a similar fashion to the ITIL lifecycle of service strategy to service operation. In both cases, the solution to the customer needs to be delivered as timely as possible.

You can’t manually approve every request as this would block the flow in the IT value stream. So the creation of standard change types assist in identifying low-impact, repetitive, and easy to fix types of requests.  LeanIT likes standard work, as once you know if the request or change will not place the organisation at risk of losing a customer or wasting money, you can then automate the decision process to flow the request to the design phase, if required. If it will impose a risk or loss, then the request can be routed to a more formal approval process that can also be leaned over time.

Change should control every aspect of a release (the doing process of an approved change), so we have to look at all of the places change gets involved to help design a fast, flowing stream across IT, and ultimately one that works from the customer (pull) instead of IT pushing releases to the customer.

So where does or should change get involved?

An example:

The above could form the basis of a release process. I am sure more questions are needed, but if we allow the various teams to continuously improve the above, we can release valued services into the organisation. The teams might use lean methods such as kanban boards to control work, kaizen to improve work and agile or DevOPS to get services developed and agreed.  Another aspect of lean that the table demonstrates is waste removal. If the change gateposts help to reduce defects, re-work, wait time between tests via automation or script reuse, for instance, then the flow of the value stream is enhanced end to end. Removing or automating/facilitating the gates in a formal process will also help increase flow resulting in a better time to market, quality enhancement, productivity improvement and cost reduction.

Configuration management – the needed process for ITSM & lean success

To be effective (first) and efficient (second), we need data.  Where are requests, business cases, regulatory and architectural requirements for design, code, tests, or service acceptance criteria kept for example? We turn data into information to gain knowledge to deliver value. Configuration management is the data to knowledge management process. The information in a configuration management database (CMDB) can be used to enhance the way a process, team or tool performs. For instance, if we create a cycle of CCRCCR: (change to configuration to release to change to configuration to release…) to be as fast as possible; then the agility of creating solutions in a timely manner becomes our standard culture or way of working.

How do we start?

I suggest by mapping the value stream, as much as possible, from end to end.  At first you may only be able to do the parts internal to IT but keep adding until you have the entire value stream from requester to customer mapped.  Lean value stream mapping helps improve how an IT organisation, business enterprise and partners create and improve ways of work.  Get as many representatives as possible involved in a mapping exercise and use post-it notes to visualise the current way of working.   Try to get the people that do the work involved as this generates buy-in for future change improvements.  Your post-it notes could include time of steps, teams involved, tools used, etc.  Don’t trust what you create in a conference room.  Go out and see (lean calls this “gemba”) to validate your understanding.

Now return to the conference room armed with your knowledge and improve the flow of the stream (steps). Add a few measures to control the flow of the stream and most importantly BEGIN.  Don’t wait for the tool changes or other procrastination reasons: start using the new way. Check how changes are approved, the steps performed to create a release, the results of any improvement (agreed and tracked) and use the CMDB to maintain the information such as your review of other ITSM processes. You can continue to create a unified view of your IT practices, processes, tools, capabilities, etc. The lean trick is to make checks or improvement a daily part of work, not something owned by the program team, but by the people doing the activities all along the stream. Let them own and celebrate the success.

Set some stretch goals for how long it should take to agree a requestor, how fast to perform a release etc. Look at quality, productivity, stock reduction (number of tests or environments needed) as examples.  PLEASE note that cost is a benefit and if you see that as a target it may be viewed as a job-cutting exercise when it should be viewed as a job enhancement opportunity.

Please let me know what you think and try blending Lean into your ITSM world.  


Friday, 23 May 2014

Why Process Mapping for improvements realisation and organisation maturity are linked

We do a lot of work with clients in the areas of Business Process Improvement and Systems Implementation.  When supporting clients in these spaces, we find that mapping current and preferred process states will reveal enormous and broad value.  Overlaying these maps with our practitioner lens reveals all kinds of opportunities to:

  • Understand the user experience
  • Reduce complexity and process time
  • Define and assign accountabilities
  • Understand and optimise interfaces and handoffs
  • Define capability and skill requirements
  • Inform change plans and change ‘hot spots’

We are yet to see a process improve itself, however with the right people and the right focus there are masses of value there to be realised, and generally a set of quick wins that can provide a momentum for change.

Of significant value is the extent to which process mapping informs change and communication planning.  What underpins any successful process is clarity, accountability and performance expectation – sound familiar?

Many organizations look to Lean Six Sigma (LSS) in order to meet bottom-line expectations or even just to survive in a competitive business climate. After being enticed by the potential of a LSS program to dramatically improve business performance, leaders often dive head-first into a deployment.

Unfortunately, they may not understand that as an organization they are far from mature enough to utilize LSS in a meaningful way. When the LSS program does not come to fruition as expected (whether expectations were realistic or not), it puts a bad taste in everyone’s mouths for quality improvement practices.

For a more positive experience with process improvement, a company must first assess its maturity level in regard to quality management.

Stating the Obvious

On average, approximately 94 percent of all quality management implementations fail. That statistic can be argued, but suffice it to say that the number of implementation failures is extraordinarily high. The greatest factor in failure is a lack of organizational maturity in quality management systems and trying to implement far above a company’s current state.

Should an organization seek to reduce variation in a process when it has not established standard work for that process yet? The answer is obviously “No!”

But one of the questions that most leaders fail to ask is: Should I be seeking to implement LSS projects when none of my team members understands how to properly manage a project? The answer is a slightly less obvious “No!”

These questions and answers may seem obvious to anyone within the LSS universe, but they are not obvious to an uninitiated organizational leader.

A Quality Management Maturity Model

To get the biggest bang for its buck and have an effective implementation, a company needs to be clear on where it is starting from on the quality management maturity scale, and thus where effort should be expended. Leaders can identify their organization’s maturity level using the model shown in the figure below.

Quality Management Maturity Model

This figure shows a clear progression in quality management processes, with one process building on the previous process once competency is reached at any given level. Notice that Six Sigma is at the far right; tacklingvariation should not be contemplated until the vast majority of waste is eliminated from the system. In most organizations, there is not just low-hanging fruit, there is fruit lying on the ground that will rot if it is not picked up and used.

Focused waste-reduction projects should not take place until employees are properly trained to manage projects under the constraints of time, cost and quality – which become the areas for targeted Lean projects to reduce time, eliminate costs and improve quality.

From a business perspective, what would an executive in a business that is thinking about starting a quality program see? There will be a cadre of those in the organization that hold sway because they represent the organizational knowledge bank for getting the work done – the way it has always been done. And the way it has always been done is haphazard, and purposely so, as it provides power to the cadre. Chaos is ever-present so that the cadre is able to regularly pull the organization together to meet a deadline or back from a financial brink. The work areas will be cluttered and only the cadre will be able to find what is needed.


As shown in the figure, 5Ss (sort, straighten, shine, standardize, sustain)should be the first process implemented so that everything involved in any given process can be put in place and itemized. The cadre will fight this as a waste of time and intrusion into their work areas. A slowing in production may take place until the cadre realizes that the quality program is there to stay. On the flip side, there will be employees who want to see change as they have been victims of the cadre and will push to accomplish the work in spite of any hampering efforts from the cadre.

Standard Work

The next phase is to hold multiple kaizen/kaikaku (“change-good”/ “change-great”) blitzes, at least one in each section of each department in the organization. These blitzes should be held prior to training the majority of personnel in Lean so that teams can fully explore the nature of the problems their divisions face in their current processes. All employees should participate in the identification of what that work is and how to best accomplish it; the group as a whole can determine a final task list of what will be the standard work going forward for each process. With those task lists combined, a standard value stream will be mapped for all to follow.

The cadre will push back hard at this point as they will be afraid of losing control; however, they will be unable to stop the momentum of the process improvement deployment. They may shut down completely and self-identify as roadblocks. Other cadre members will identify as new leaders committed to the process, and standard work will be set in place as long as the executive team show unequivocal support for it.

Project Management

If the organization gets past the standard work stage, it is ready to be managed with a focus to time, cost and quality factors as processes are developed and discrete projects are identified. The organization can begin to be managed with a focus to time, cost and quality factors as processes are developed and discrete projects are identified. At this stage, personnel can be trained in project management combined with Lean. This is also where the design of the future state of the organization can begin.

Mature Lean

With the future state clarified, it can start to be set in place through systems mapping, planning and waste reduction. These changes will drive the bottom-line impact of the quality process and ensure sustainability as the organization becomes mature in its use of Lean.

Six Sigma

Now the organization can tackle variation through the use of Six Sigma in the tracking and analysis of outputs of tasks and processes to ensure that what the customer wants, the customer is getting. As capabilities grow, new ideas identified from ongoing kaizen/kaikaku blitz events can begin to take shape in an environment where Design for Six Sigma is built in from the start. This can drive innovation, new revenue generating services and strategic engagements, aid in rapid deployment, and will not cause disruption of existing systems and processes.


There are two battles to face in working through the quality management maturity model.

  1. All executive leadership must be on board with the process improvement deployment.
  2. The cadre members that become roadblocks to progress must be removed or co-opted.

How can the rest of the quality management maturity model be achieved? There are only three words to focus on after that: training, training and more training!

Thursday, 1 May 2014

Phases of gap analysis

A gap analysis is a tool that ITIL recommends organizations use to compare their current state to some future desired state. The idea of a gap analysis is to help an organization understand the path and commitments in terms of resources and time that it must make to achieve a particular goal.

The Continual Service Improvement doesn’t provide too many specifics about a gap analysis or how one should be conducted. When I’ve been involved in gap analyses, I tend to think of the activities as occurring in several phases. Following are the phases of a gap analysis and some of the activities that occur during those phases.

Phase I: Planning 
The initial phase of a gap analysis involves planning the various gap analysis activities. This includes finalizing the scope of the gap analysis, agreeing to gap analysis questionnaire content, and determining the format of the gap analysis. During this phase, relevant stakeholders are identified, the formal communication plan is established, and the deliverables are specified. At the end of this phase, the gap analysis is formally kicked off in the organization.

Phase II: Discover and Review Background Information 
During this phase, those conducting the gap analysis review various sources of information. These sources of information include existing policies and process descriptions, service documentation, process flowcharts, roles and responsibilities, process outputs, communication plans, CSI activities and plans, service level agreements and associated reports, and other information as applicable. The purpose of this phase is to establish the organization’s formal intent for service management activities.

Phase III: Stakeholder Interviews 
The stakeholder interview phase involves interviewing existing service owners, service managers, process owners, process managers, and any other relevant stakeholders in the organization. The interviews are conducted based on the questionnaires established during Phase I and should investigate based on the information discovered during Phase II.

Phase IV: Draft Gap Analysis 
Based on the results of prior phases, an intermediate assessment is drafted and reviewed with key stakeholders. Significant portions of the gap analysis are reviewed and adjusted with key stakeholders, and the gap analysis is validated with organizational sponsors.

Phase V: Complete Final Deliverables 
The last phase of a gap analysis involves making any final documentations to the gap analysis report; providing short, medium, and long-term recommendations; and conducting a formal gap analysis review meeting. During this phase, the gap analysis project is formally closed and the organization presumably start working on some of the items identified during the gap analysis.

A gap analysis is one of the most valuable tools described by ITIL. When conducting a gap analysis, following a logical, phased approach results in usable deliverables that help the organization achieve its vision.

Sunday, 27 April 2014

Are you a terrible manager OR just an imperfect fit?

A few month ago, the Lead consultant of a large multi-national consulting company asked me to join them in a planned business review session with a large manufacturing company overseas.

I read the brief and quickly concluded it is a great idea. The big problem: I didn't see how managers could modify their leadership style to meet the coaching and training needs of each new hire. Instead, This lead consultant suggested hiring people who already fit their business approach to management. 

I later researched this concept of Managerial Fit and described the process in The Essential Guide for Hiring.

The candidate assessment starts by first categorizing managers into six basic styles based on how hands-on or hands-off they are. During the interview, candidates are categorized into six companion styles based on how much support and direction they want and/or need. The two styles are then compared to determine their Managerial Fit.

Basic Managerial Styles: How Managers Manage Their Team Members

Some managers overdo it. Others don't do it at all. As you read the following descriptions, position yourself and/or your manager on the grid from very controlling on the left to largely uninvolved on the right. Most managers have one dominant style but are flexible enough to deal with situations that require adjacent styles. For example, coaches can normally become trainers or delegators as necessary.

1. Controller: This is the directive micromanager style that oozes "my way or the highway."

2. Supervisor: These people need to tightly control a repeatable process using metrics and constant follow-up.

3. Trainer: These managers excel when working closely with people to teach them new skills. The best have the ability to back off and let people learn on their own.

4. Coach: These managers tend to work best with people who have most of the skills needed to do the job, but they are more than willing to coach them through new or problem areas. On an ongoing basis, they provide regular guidance, support, and feedback.

5. Delegator: These managers provide broad direction and regular feedback. They typically agree on the results needed but leave the detailed process up to the person.

6. Hands-Off: These managers tend to provide very little direction and limited feedback. They won’t intervene unless things go awry.

When interviewing people for management positions, I ask candidates who they like to hire and why. This allows me to assign them into one or more of these categories.

Typical Subordinate Styles: How Staff Members Need and/or Like to Be Managed

Some people need more direction than others and some want more than others. When I ask candidates to describe their major accomplishments and where they’ve excelled, I find the role the manager played. Patterns quickly emerge, depending on how much support, direction, and training the person needs.

1. Dependent: These people need constant direction, follow-up, support, and handholding.

2. StructuredThese people perform best when required to do repeatable tasks on a continual basis.

3. Trainable: These people have the ability to learn and apply new skills but need extra support and coaching before they're left on their own.

4. Coachable: These people have the basic skills but are more than willing to take direction in areas where improvement is needed.

5. Manageable: These people prefer to be given lots of leeway in how the work needs to be done but are very amenable to support during the planning phase and in reviewing results.

6. Independent: These people prefer to be given broad direction and full responsibility for achieving the agreed upon result.

Managerial Fit problems occur when the manager's style does not complement the subordinate's needs or wants in terms of training, direction, and support. Problems occur on the extremes, or where the manager or subordinate isn’t flexible. For example, a very controlling manager hiring someone who requires more independence is a recipe for frustration and underperformance. Expect similar problems with a strong delegator-style manager who hires someone who needs extra coaching and direction.

Otherwise good people tend to underperform for three big reasons: the work itself isn't appealing or motivating, or they don’t get along with their manager.

Good managers underperform when using a skills-based job description to define the work, which leads to hiring people who aren't motivated to do the work since it wasn't clarified properly, or demotivating these same people by over- or under-managing them. Managers control the complete solution. Defining the work upfront using a performance-based job description will solve the first problem. Conducting a performance-based interview will solve the second. And even if the person isn't a perfect manager, understanding Managerial Fit will minimize the third.

Monday, 31 March 2014

Differences between successful and unsuccessful people

Below are the 16 differences between successful people and unsuccessful people claim;
1. Embrace change vs. Fear change
Embracing change is one of the hardest things a person can do. With the world moving so fast and constantly changing, and technology accelerating faster than ever, we need to embrace what’s coming and adapt, rather than fear it, deny it or hide from it.
2. Want others to succeed vs. Secretly hope others fail
When you’re in an organization with a group of people, in order to be successful, you all have to be successful. We need to want to see our co-workers succeed and grow. If you wish for their demise, why even work with them at all?
3. Exude joy vs. Exude anger
In business and in life, it’s always better to be happy and exude that joy to others. It becomes contagious and encourages other to exude their joy as well. When people are happier they tend to be more focused and successful. If a person exudes anger, it puts everyone around them in a horrible, unmotivated mood and little success comes from it.
4. Accept responsibly for your failures vs. Blame others for your failures
Where there are ups, there are most always downs. Being a leader and successful businessperson means always having to accept responsibility for your failures. Blaming others solves nothing; it just puts other people down and absolutely no good comes from it.

5. Talk about ideas vs. Talk about people
What did we all learn in high school? Gossip gets you nowhere. Much of the time it’s false and most of the time it's negative. Instead of gossiping about people, successful people talk about ideas. Sharing ideas with others will only make them better.
6. Share data & info vs. Hoard data & info
As we all learned in kindergarten, sharing is caring. In social media, in business and in life, sharing is important to be successful. When you share you info and data with others, you can get others involved in what you are doing to achieve success. Hoarding data and info is selfish and short-sighted.
7. Give people all the credit for their victories vs. Take all the credit from others
Teamwork is a key to success. When working with others, don’t take credit from their ideas. Letting others have their own victories and moments to shine motivates them and in the long term, the better they perform, the better you'll look anyway.

8. Set goals and life plans vs. Do not set goals
You can't possibly be successful without knowing where you're going in life. A life vision board, 10 year plan, 3 year forecast, annual strategic plan, and daily goal lists are are useful tools of the mega-successful people in your life. Get your vision and goals down on paper!
9. Keep a journal vs. Say you keep a journal but don’t
Keeping a journal is a great way to jot down quick ideas or thoughts that come to mind that are not worth forgetting. Writing them down can lead to something even greater. You can even use mobile apps or your Notes function in your phone. But don’t fool yourself by saying you keep a journal and not following through.
10. Read every day vs. Watch TV every day
Reading every day educates you on new subjects. Whether you are reading a blog, your favorite magazine or a good book, you can learn and become more knowledgeable as you read. Watching television, on the other hand, may be good entertainment or an escape, but you'll rarely get anything out of TV to help you become more successful.
11. Operate from a transformational perspective vs. Operate from a transactional perspective
Transformational leaders go above and beyond to reach success on another level. They focus on team building, motivation and collaboration across organizations. They're always looking ahead to see how they can transform themselves and others, instead of looking to just make a sale or generate more revenue or get something out of the way.
12. Continuously learn vs. Fly by the seat of your pants
Continuously learning and improving is the only way to grow. You can be a step above your competition and become more flexible because you know more. If you just fly by the seat of your pants, you could be passing up opportunities that prevent you from learning (and growing!)
13. Compliment others vs. Criticize others
Complimenting someone is always a great way to show someone you care. A compliment gives a natural boost of energy to someone, and is an act of kindness that makes you feel better as well. Criticizing produces negativity and leads to nothing good.
14. Forgive others vs. Hold a grudge
Everybody makes mistakes; it’s human. The only way to get past the mistake is to forgive and move on. Dwelling on anger only makes things worse - for you.
15. Keep a “To-Be” list vs. Don’t know what you want to be
A “To-Be” list is a great way to strategize for the future. I want to be an elected official one day. I want to be a TED speaker. I want to be the CEO of a public company. I want to be a great father and husband. Unsuccessful people have no idea what they want to be. If you don’t know what you want to be, how can you achieve success? What do you want to be?
16. Have Gratitude vs Don't appreciate others and the world around you.
Moments of gratitude, each and every one, transform my life each day- and unquestionably have made me more successful and more happy. The people who you are grateful for are often the ones who have a huge part in your success. Be sure to thank everyone you come in contact with and walk with a spirit of gratitude and appreciation and even wonder, about the world around you. Gratitude is the ultimate key to being successful in business and in life.
© Copyright 2012 Gateway to Process Improvement LtdWebsite design by Toolkit Websites