The popularity of Agile project methods is exploding across corporate America.  The shift to increased flexibility and responsiveness to customer needs or changing circumstances is long overdue!  The principles of Agile project methods can be applied to a broad spectrum of situations far beyond pure software development.

 1)      1. Lean:              perform only those tasks and activities that contribute directly to the project products.  Keep administrative tasks to the bare minimum.  For example use discretion in deciding whether to write up change documents and decision documents and to what degree of detail is needed.  Maintain controls at practical checkpoints and limits.

      22.    Speed:           focus on the tasks at hand.  Don’t allow yourself to be distracted by requests to receive sales pitches on new technologies or participate in time consuming administrative reviews while the project is in full flight.

3)       3. Proximity:      team members need to communicate directly with one another at all times.  Similarly the project team and the business/customers need to be able to communicate directly a lot.  Face-to-face communication is best.  Voice-to-voice is next best. 

4)       4. Attentiveness – stay in the moment:     circumstances are always changing.  The business has new insights and asks for a change to a product; team members get sick; hardware fails; software flubs.  Size up the situation quickly and involve team members who may have expertise and get some quick opinions (see item 2 above “SPEED”).  Weigh your options, then decide on the altered course of action and put it into play.  Continue to pay attention as unexpected results may develop and more course correction may be required.

The key is to expect change and welcome the changes.  Stay on top of the changes and manage the change rather than having the changes run you.  You and your team will have more fun and achieve better results faster with the Agile mind set.

High performing managers in IT bring a balance of action and introspection.  A project plan describes the tasks and activities that team members need to complete within specified time limits.  Rarely is there a pause just to observe what’s going on in the project and to think.  The reflecting and introspection usually takes place after the project is over when it’s too late to do anything to change outcomes.  By that point the motivation of the manager and team members has shifted to wind down and recovery mode.  The energy is no longer there for high quality effort.

Admittedly, some of the tasks may have “think time” implicitly built into them.  I make the case for building in explicit events to halt and reflect on what’s working well, what isn’t, how the team is growing or evolving, and how the customer is feeling, etc.  Plato expressed the notion that “a life unexamined is not worth living.”  I suggest that a project unexamined is sub-par. 

The amount of time required for some mid-course introspection should be small.  Your thinking should be only slightly structured to ask yourself a few key questions about what has taken place and what is likely to occur in the near future.  However the insights you gain from the short pause of sitting and thinking can provide valuable benefits to you and your organization.  Build in some short breaks for thinking and then leap back into action with improved perspectives and possibly new ideas.

Intensity is necessary for us to achieve our best.   Achieving our best is important because achieving less leaves us unsatisfied.

It is not obvious which level of service or product is our best and which level is less than our best.  We get subjective feedback when we push to our limits.  That feedback of hitting our limits is the most accurate measure we have.

What happens when we push to our individual limits or team limits?  Most often growth occurs in response to the pressure.  Growth is good.   Very often breakthroughs occur when we push to our limits.  The limits of individual and team capacity are fertile ground for creative solutions. 

Intensity creates clarity.  Intensity forces away distractions.  Intensity equals focus. 

The ability to focus is a learned skill.  As with most skills, some people have more natural ability.  Nonetheless, whatever ability we have, we can improve with practice and discipline.  Practice involves shutting out distractions ruthlessly.  Be consistent and repetitive to hone the focus skill.

As a leader, steadfast focus and concentration inspire trust in our world of ADHD flakiness.

Of course rest periods and breaks are needed.  Life is a marathon.  Pace yourself and get nutrition along the way.  Use intense focus times judiciously as it is tiring. 

 To respond effectively to a people situation on an IT Project you will need to consider the various aspects of the context of the situation.  On of three critical aspects of the context consists of the organization culture profile.  As you can imagine a management action that is effective in one organization culture, may be disastrous in an organization with a very different culture.  For example, in the case of an ongoing individual person performance issue, one organization may deem demotion of the person as an entirely appropriate consequence.  In other organizations, that action would be considered wrong and lead to a range of other people problems.    

 Furthermore, when consistent leadership is in place for extended periods of time (years), the culture of the organization tends to become more firmly entrenched.  People who have personal values out of sync with the organization values will leave over time.  In their place, people who have similar values will be recruited and want to join.   At the same time, people with the strongest affinity to the organizational values and who are at least adequate performers, will tend to be promoted, thus further embedding the values and behaviours of the organization.

 Thus, developing an enlightened insight to the organization factors is an essential step in formulating the best response to a people challenge.  The organization factors consist of seven (7) criteria pertinent to people management.  The 7 criteria include:

1. Decision making style
2. Appetite for risk
3. Extent of profit drive
4. Management control type
5. People versus task orientation
6. General work ethic
7. Organization layers

 This edition of the blog does not lend itself well to the thorough examination of the seven factors that is required to become proficient at profiling organization cultures.  Subsequent editions will explore each of the factors in greater depth.   Instead, a couple case studies are provided to give a sense for the wide diversity of organization cultures that exist and hence the wide diversity of management actions that need to be considered.

 The first case involves a large national manufacturer that had completed a corporate merger with one of its competitors.  The IT project involved the migration of processing and data from the two disparate systems to one of the systems.  The implementation of such a large scale operation to a new system was rife with risk.  The organization decision making style was typically collaborative.  The organization had a strong appetite for risk and a strong profit drive.  Failure of managers was dealt with by termination.   The organization’s management control type was rigid and detailed.  The organization was task oriented and the general work ethic very demanding.   When examining the alternative for implementation, the approach used was to rely on the practice of collaboration and analyze the pros and cons with all of the groups of affected stakeholders in a series of workshops.  Ultimately, a “Big bang” implementation was selected.  Relying on its rigorous management control and long hard hours by the project team, the organization successfully mitigated the risks and implemented on schedule and within budget.

 In the second case, a public sector organization undertook an IT project to implement an enterprise software application to replace all of its core administration functions.  The administration functions for this organization had major client facing components as well as a highly critical executive reporting component.  Stringent government regulatory components were a vital part of the overall solution as government funding for the entire organization depended on compliance and reporting.  The marketplace was dominated by two software packages from vendors from another country.   One package was chosen and implemented over a period of three years.  Due to significant differences in the national government reporting requirements, one of the ancillary business functions was excluded from the scope of the original implementation.  It was decided that a subsequent project would be undertaken to custom develop software for the ancillary business function and integrate the custom software with the packaged software.  The manager of the ancillary business function was very reluctant to pursue the project which jeopardized the success of the project.  The organization decision making style was autocratic.  The organization had no appetite for risk and would rather delay projects and exceed budgets than risk a failure of functionality which could become subject to public criticism.  The organization had no profit drive and thus cost containment was a relatively lower priority.  The organization had generally lax management controls and was oriented towards people concerns rather than task productivity.  The general work ethic in the organization was low intensity with shorter than average hours logged by most staff.  The approach to overcoming the issue of the reluctant manager needed to consider the above factors to be most effective.   The approach need to avoid risk and not require intense work during the project.  By first focusing on building trust with the single manager that had both the authority and concern, it was possible identify a superior and lower risk solution than the one originally envisioned.  The project was a major success.

Context of IT Situations sets the boundaries and constraints for formulating management action to reaffirm control of the situation. 

Context when we consider project situations is made up of three aspects, 1) the particulars of the project, 2) the categorization of the organization within which the situation occurs and 3) the categorization of the manager

This article will discuss the factors to be considered in the first aspect, the particulars of the project.

As experienced and trained project professionals know, the three major constraints that define projects include project schedule (time), project budget (money) and project scope (quality).  In project management lexicon, these constraints collectively are commonly referred to as the “triple constraint”.  In theory, as the project unfolds and events that negatively impact project delivery transpire, one or more of the three constraints must be adjusted.  However, in the practical realities of projects, the options are even further limited.  That’s where IT Situational Analysis comes into help identify and select the best options for management action.  I will use a couple summarized case studies to illustrate the concepts.

In the first case, the client had a leading position in its industry built on strong customer relationships.  The organization however, had a below average record of completing projects on time.  A significant IT project arose out of a commitment the CEO made to one of their largest customers to have a technology in place by a specific date.  The project was highly visible to the entire executive in the company and required participation form the major divisions. The budget allocation and time frame were reasonable at the outset.  A strong team of technical specialists was assigned.  A detailed project plan was prepared and generally accepted project management practices were followed.  As the first critical milestone approached, it was discovered that design specifications of one of the essential four technical components was both inaccurate and incomplete.  The design had to be redeveloped from scratch.  To compound the challenge of the issue, one of the Senior Technical Specialists for that component was away and un-reachable.  Normal project management practice posits that minimally three potential solution avenues exist. First, time could be added to the project schedule to allow for the necessary rework. Alternatively, cost could be expended to add more people resources in an effort to accomplish more work without extending the schedule.  As a third option, the scope of work in another discretionary area might be reduced to accommodate the extra work in the essential area.  In the case there really was only one option!  The milestone date could not be extended due to the CEO commitment to the customer.  The scope could not be reduced as there were no discretionary work items to reduce.  The only option was to add new Senior Technical Specialists at an additional cost.  The only viable alternative was executed.  The team worked very long hours for two weeks non-stop and the critical milestone was achieved.  The incremental cost was incurred and the project went over-budget in the category of resource costs. 

In a second case, the organization undertook an IT project to consolidate IT operations from multiple geographic locations into a single location in order to reduce costs.  The project was highly visible to all executive in the organization and the reduction targets had been publicly announced.  The project involved considerable risk as processing of several large mission critical systems were being moved from one city to another in a single weekend.  As the second milestone of he project approached, one of the external vendors of the software the organization licensed to run the systems steadfastly refused to allow the organization to move the processing from its current city to another processor.  The terms of its one-sided licensing agreement provided such a restriction and thus the vendor was acting within the legal provisions of the signed agreement.  The project was in jeopardy of failure.  Normal project management practice dictates that minimally three potential solution avenues exist. First, time could be added to the project schedule to allow for the negotiation with the uncooperative vendor. Alternatively, cost could be expended to add more people resources in an effort to accomplish substitution of the comparable products from a cooperative vendor (i.e. more work) without extending the schedule.  As a third option, the scope of work in another discretionary area might be reduced to accommodate the extra work in the essential area.  In the case again, there really was only one viable option!  The project completion date could not be extended due to the dependence of the entire organization on the original date.  Increasing the project budget in this cost sensitive organization would be career suicide for the Project Manager and the CIO.  The only viable option was to change the original scope of the project to exclude lower priority functions and include the substation of products from an uncooperative vendor for those of a cooperative vendor.  The uncooperative vendor was terminated; the products of a cooperative vendor were licensed and successfully installed within the original timeframe and the overall budget.

In each of the cases above, knowledge of the respective organization’s pertinent biases and behavioural norms was required in order to formulate the appropriate management action to a potentially disastrous turn of events.  This knowledge of the organizations biases and behavioural norms form the first important part of IT Situation context.

People Side of Technology- Unconventional Solutions Have Big impact

In my first article I introduced the importance of the often neglected “people side” of technology in business. 

One of the aspects of the managing people problems that technology professionals often struggle with is the notion that irrefutably correct management actions and irrefutably incorrect management actions do not exist.  Managing people issues on technology projects is more of a “gray” area where certain approaches tend to work and others tend to be less effective.

A second aspect of the “people side” is that the problems are very often hidden.  Rarely does a person say “My behaviour problem is y.  X is the solution to my behaviour problem.”  Rather one encounters poor productivity (i.e. below past personal average performance or below organization standard performance) and/or negative influences and/or actions detrimental to the project.  It then remains for the manager to identify underlying causes.

At the same time it is true that technical bugs are most often well hidden too.  For those not well trained in the specific technology, the bugs can be very hard to find.  However, methods employed to find bugs in technology bear little relation to methods for finding hidden people behaviour problems.  Hence, becoming a skilled technologist does not prepare one for managing people challenges.

At the most conceptual level, there are parallels between solving technology problems and solving people problems.  The leader charged with solving the problem must first find the cause.  In both the people world and the technology world one must look deeper to find the camouflaged cause(s).  One step includes the search for anomalies in behaviour, no matter how slight.  Secondly, take note of any seemingly unrelated events that occur or artifacts that become visible around the same time as the problem.  Thirdly, look back into recent history and look for apparently innocuous changes or disturbances to equilibrium.  Most often, one or more of these will correlate and the likely cause is unearthed.

Once the cause is uncovered, the parallels between the technology world and the people world cease.  Management actions can rarely eliminate the root cause of a people problem in the way one can with failing software or defective hardware.  Often the cause of a people problem is an event of the past that cannot be undone.  What is required may well be a creative introduction of a new event to counteract the harmful past event.  The degree to which this new event is effective varies greatly depending on circumstances.

Case Example:

The Manager of a group of IT professionals in a national financial services organization had a long standing problem with one particular Senior Technical Specialist.  This Senior Technical Specialist had a great work ethic.  He was very technically knowledgeable and he consistently demonstrated commitment to quality and a sense of ownership for his work assignments.  This fellow possessed a strong sense of pride.  The problem was that he was always finding fault with managers across the IT department.  He continuously grumbled to his peers about the short comings in the managers’ (who did not possess deep technology knowledge) decisions.  His not-so-subtle complaining was a drag on morale and was affecting the productivity of others.

The standard management response might typically include some form of reprimand possibly including a written note on the personnel file of the Senior Technical Specialist.  Probably a more common management response would be to do nothing at all and hope the problem goes away.  Instead, the creative solution was put in place when a supervisory vacancy occurred.  The Manager of our grumbling Senior Technical Specialist, promoted him to supervise a group of Technical Specialists.  The result was transformative.  The new responsibility appealed to his conscientious work ethic.  He showed himself to be sensitive to the feelings and concerns of others, especially the Technical Specialists who reported to him.  In addition to continuing with delivery of high quality technology services, he worked diligently for the professional welfare of his charges and the overall success of the unit.        

February 28, 2012

Determining the best way to respond to human behavioural situations on IT projects is both an art and a scientific process.   Knowledge and experience from both fields is required to even have a reasonable shot at solving the dilemmas inherent to managing people on technology projects.

There are no proven methods that can be repeated in different situations to consistently achieve desired results.

Conversely, sheer imagination and creativity are rarely sufficient to formulate successful responses.

Analyzing the situation and developing a response is more like a craft in which existing material is used to construct a product.

Similar to the way in which most people learn a craft, becoming proficient at managing people behaviour situations occurs by doing the activity a lot.  It is not a process where the practitioner learns the rules and applies them mechanically.  It requires judgment and discretion.

There is also a measure of detective work involved.  It is necessary to get the “big picture”.  To do so, requires gathering evidence, often subtle clues, and coming up with a theory that explains the evidence.

There are three steps.  First gather all of the evidence.  Second, analyze the evidence.  Third, formulate the theory.

The theory and evidence act on one another in a two way relationship.  The theory flows from the evidence and perception of the evidence changes once the theory has been stated.

It is an iterative process.

The final test is to play out a response based on the theory and assess if the desired results are achieved.  Follow on response are sometimes used to improve the behavioural outcomes. 

Blog entry 1 – People Challenges in the IT Workplace

Broad experience has shown that implementing information technology (IT) in organizations is a difficult venture.  It is common place for these projects to run significantly late, significantly over budget or to fail to deliver the expected improvements.   

It is normal to blame the new technology for the problems.  However, this is rarely the case.  In actuality, the obstacles and challenges most often lay with people and organizational behaviour issues.

Confounding the matter further, IT managers and professionals typically are weak in the skills required to manage the people and organizational behaviour challenges.  In many cases it is the IT professionals who are exhibiting the behaviours that detract from the success of the projects. 

The skills for working harmoniously with people and managing behavioural challenges are very different than the hard technical skills than give the IT professionals their specials status.  The people skills are often referred to as soft skills.  These vast differences in the nature of the soft skills when contrasted to the hard technical skills may even hold the rationale for why IT professionals tend not to have the soft skills in abundance.

Recognizing the accurate source(s) of the problems is one thing.  Addressing the problems is an entirely different matter.    How does one acquire the soft skills to analyze and respond to these situations?    

There at least two aspects to the soft skills acquisition.  The first involves the skills themselves.  The second involves learning how to apply the skills adept in the wide array of situations that unfold in the course of IT implementations.  There are few resources available to satisfy the needs.  Some analogies illustrate the important distinction between these aspects is the experiences of those who play golf.   There are a variety of skills needed to advance the ball in the desired manner.  People usually acquire and refine these on a driving range (analogous to a classroom).   Inevitably, applying those same skills during scoring rounds of golf rarely works any where near as well as they did on the driving range.  There are many reasons for the difficulty in this transition. 

Medical students first spend years in the classroom learning the science and the skills of surgery.  However, it is the designed intense internship and residency program where the application of the knowledge and skill become the practical capabilities of being a doctor.  Even then it is recognized the years of experience of a doctor is a valued criteria.

Teachers learn education theory at colleges and universities, but it is as student teachers they learn how to deal with misbehaving students, demanding parents and unsupportive administration.  They learn to be teachers.

In summary the ability to apply acquired skills to “game” situations is a unique skill in and of itself.   It is this unique skill of applying the soft skills to real life situations that we will focus on in coming editions..