Tag Archives: project management

Why Do Outsourcers Deliver Better Project Performance Than Inhouse Resources?


imagesI was talking to a CIO last week about his desire to “tune” his IT Operating Model.  I asked about the symptoms he was observing that he’d like to see eliminated through the Operating Model tuning.  His answer was one I’d heard many times – but that did not lessen the passion that came across in the dialog:

When we have a project run by one of our outsource partners, it generally comes in on-time, within budget, and meets the specifications we requested.  When we take on a project internally, none of those conditions are typically met!  I’d like to see our internal resources as capable at delivery as the outsourced partners!”

The Secrets to Outsourcer Success

I’ve found that there are several reasons for the gap between outsourced and internal project performance – some obvious, others more subtle:

1.  Outsourcers live and die by their performance – it’s their business.  They are paid for results.  This leads to several typical characteristics:

  • Results are articulated very clearly – and are rigorously managed to.
  • People are held accountable for results.  Failure to deliver has real consequences.
  • Scope – and the client – are carefully and skillfully managed.  If the scope changes, so does the project schedule, cost and performance expectations.

Compare these characteristics with those of the typical internal resource.  Results are often vague and unstable.  The old cartoon comes to mind of the project leader leaving a room of programmers, looking over her shoulder and saying, “I’ll go up and find out what they want – the rest of you start coding!”  A caricature, of course, but one earned deservedly!  People are generally not held accountable in any real sense.  HR policies and fear of depressing morale and engagement render most managers impotent when it comes to accountability and consequences.  And scope often changes frequently as business clients discover more about their real needs and constraints.  Nothing inherently wrong with that, but schedule and cost should have been renegotiated but typically are not – unless there’s an outsourcer running the project!

2. Outcourcers typically dedicate resources to a project – internal resources in an IT organization typically work on many projects at the same time.  Even worse, they are often expected to simultaneously perform project work and service delivery work, which is often hard to predict and frequently requires an urgent response.

The productivity and quality cost of this type of multi-tasking has been demonstrated time and time again.  Ever since the Coding War Games, led by Tom DeMarco and Timothy Lister (see their wonderful book, “Peopleware: Productive Projects and Teams“) in the late 1970s, key factors that impact project productivity have been studied, illuminated and verified.  There’s a plentiful supply of data about how long it takes a project team member to “re-engage” with his project, and the consequent productivity loss of this type of multitasking behavior.

3. Outsourcers typically have projects managed by very seasoned Project Managers working to a consistently practiced and proven project methodology.

Yes, I know this is supposedly the case with in-house resources, but from my experience, it often does not hold up in practice.  Just about anyone can acquire the title “Project Manager“, whether or not they actually have the skills.  Certifications such as PMP theoretically mitigate this, but I’ve seen PMP-qualified resources somehow forget everything they learned about project management once they get into the heat of battle – presumably due to the effects of 1. and 2. above.

What To Do to Improve Inside Project Performance?

There is no magic to this:

  1. Articulate clear expected results.
  2. Hold people accountable, and ensure that consequences are made real – both for excellent performers (e.g., promotion, recognition, added responsibility to train and coach others) and for poor performers (e.g., performance related intervention, demotion or reassignment, termination.)
  3. Manage scope.  This does not mean forcing the business client to live with a spec that may be unacceptable  – but it does mean renegotiating cost and schedule when performance needs change.
  4. Recognize that most project work is a full time role – dedicate project resources and isolate them from the day-to-day demands of service delivery.

So, why don’t these things happen?  I don’t know – you tell me!

Related articles
Enhanced by Zemanta
About these ads

The Keys to IT Demand Management


Once again, I’m posting in response to a reader’s emailed question.  The reader wrote:

While trying to understand the difference between Demand management, Portfolio Management and Project management from an IT Infrastructure Service delivery perspective, I stumbled upon your blog and found some interesting reads.  Could you please share your thoughts on how to define Demand Management for a service delivery company – what is in-scope and out of scope?”

IT Leaders Tend to Focus on Supply Management

Delivering IT products and services has been challenging since businesses first became IT-dependent.  There’s lots of complexity, layers of specialization, an unnatural separation of IT producer and consumer, and significant capital investments.  Exacerbating this is the typically high ongoing maintenance and life cycle costs, rapidly changing generations of technology, with resulting technological obsolescence.  As a result, IT leaders have focused far more on supply management – figuring out their supply chains, providing security, integrity and stable services, squeezing out costs,and so on.

Meanwhile, the demand side has typically received short shrift.  Demand chains are unclear at best, and complexities such as the IT infrastructure implications of supply activities and changing technologies are opaque.  IT planners have a hard time answering fundamental questions such as, “What’s in the pipeline for the next 6 months?” or, “What is our projected resource utilization for the next 6 months?”

There are also common problems where demand meets supply – IT delivers products and services that business users don’t understand, did not really want, or did want but do not know how to extract the business value.  It is generally seen that IT’s job is to “deliver” the solution, but not to ensure it is working to full effect.

So, What is IT Demand Management?

According to Wikipedia:

Demand management is a planning methodology used to manage and forecast the demand of products and services. In business, the term is used to describe the proactive management of work initiatives (demand) with business constraints (supply).” (Bold font added for emphasis)

I like to think of IT demand management as:

A set of disciplines, tools, and governance mechanisms designed to surface, stimulate and shape business demand for IT products and services in balance with supply constraints.”

In other words, given that IT supply is always limited, how do we surface and shape demand to get optimum business value from limited IT supply?

Key Elements of IT Demand Management

Getting demand management working effectively requires an orchestration of several techniques and processes – and ultimately, a moderate to high level of Business-IT Maturity (earned through the focus on supply management mentioned above).

The key elements include:

  • Portfolio Management is an important demand management technique and tool (and, if implemented properly, a governance mechanism).  Portfolio Management can help balance IT demand across time horizons (short versus long term), across risk/reward profiles (high risk/high potential return, low risk/low potential return), across business units or business processes, and across IT investment categories, such as IT projects and programs versus IT infrastructure.  Portfolio Management can make these balancing acts explicit so that they become strategic choices (Portfolio Planning) rather than the result of natural “drift.”
  • Product and Service Life Cycle Management.  In the world of IT, creating a solution is a fraction of the cost – maintaining and evolving it, keeping up with changing business needs and shifting technologies is costly.  Traditional accounting practices add to the load as depreciation of capital expenditures creates an ongoing drag on funding sources.  So, ensuring that life cycle costs are taken into account with the initial investment, and managing product life cycles to ensure that necessary investments are made, and unnecessary products and services are retired in a timely fashion is a key Product and Service Management function.  Also, maximizing ‘reuse’ of products and services – “why bring in yet another Customer Relationship Management system when we already have three” is a common refrain that often goes unanswered.  Finally, understanding cost drivers, and influencing business behavior towards ‘responsible’ consumption of IT products and services is an important part of the demand management equation.
  • The role of the Business Relationship Manager (BRM) – the key interface between business and IT.  The BRM is an important demand management channel.
  • My reader’s question asked about what Project Management has to do with IT Demand Management.  Project Management is mostly a supply management technique.  However, poor project management can negatively impact demand.  For example, I’ve seen business behavior that essentially says, “I will ask for more than I need because I know IT will screw it up!”  Or, “I will ask for as much as I can get because I know nobody is keeping count on the results!”)
  • Though not mentioned in my reader’s question, Program Management embodies an important set of both Demand and Supply Management disciplines, tools and governance mechanisms.  Program Management is a critical linkage between Portfolio Management and Project Management.
  • Effective demand management also requires agile supply capabilities.  This is one of the best reasons for techniques such as selective outsourcing and cloud computing – being able to flex up as demand increases and scale back when it wanes.

The COBIT and ITIL Trap

I’m generally supportive of frameworks such as COBIT and ITIL – there’s no really good reason to reinvent these wheels – they embody ‘good practice’ for IT governance and service management respectively.  However, they have to be customized to fit your environment, and many companies short-change this activity and end up with processes-in-theory, but not in practice.  In other words, the processes, control objectives, and so on that they think they have are not what people actually do!

Another problem these frameworks can induce is deluding their proponents into thinking that tools and processes solve the problems of demand management.  Yes – you need clear, transparent demand (and supply) management processes, and these can certainly benefit from good frameworks and tools.

However, effective demand management hinges on strong business understanding and buy-in, highly skilled Business Relationship Mangers (or whatever you call people in that role) and robust business-IT governance.  In particular, governance must address how demand is justified, funded, and how benefits are tracked and accountability held for them.

 

Graphic courtesy of Vendeka

Related articles
Enhanced by Zemanta

Projects, Programs and Portfolios – 3 Common Traps


I recently got the following email from a reader of my blog:

I am a student of project management…  Thank you for the article Project vs. Program vs. Portfolio Management.  However, I have a challenge deciphering the relationship between these terms and I think an illustration using an example would help me a lot. I kindly requesting you to help me with that. May you help me please!”

I replied with an analogy, rather than an example, and, per her response, I guess the analogy helped!  Given that the post she referred to continues to be among the most highly read posts on my blog, I thought I’d repeat the analogy here, and use it to discuss three common traps I see IT leaders falling into.

Managing an Investment in a House

Let me take an example of owning a house.  (By the way, the details behind this analogy are totally fictitious!)  I may decide that I am going to invest $20,000 per year in this house.

I decide to allocate this $20,000 into a portfolio.  I will spend 20% on recurring operating costs (home owners fees, real estate taxes, etc.)  I will spend 40% on improvements – things that make the house nicer to live in and hopefully add value to the house.  I will spend 20% on maintenance – painting, pressure washing, annual contracts for maintaining heating and air conditioning, etc.  And I plan to spend the remaining 20% on major repairs – a new roof every 12 years, new air conditioning, etc.

Essentially, I have defined my $20,000 annual investment into a portfolio model.  This helps me manage my spending and hopefully lets me balance investment in future value (improvements) against necessary ongoing costs.  I can track my spending by portfolio category and either adjust my portfolio or get better at managing costs.

My Handicap Access Program

As part of my improvement investments, I decide that I want to make the house handicap accessible.  So I create an Handicap Access Program.  The goal of this program is to make the entire house conform with handicap access regulations.  I believe this will make the house more valuable on the market given the demographics (aging population).

My Handicap Access Program will take about 3 years to complete and will be funded out of the 40% “improvement” bucket of my total $20,000 portfolio – i.e., approximately $2,500 per year over 3 years.

The Handicap Access Projects

My Handicap Access Program will comprise 5 major projects:

  1. Ramps at the front and rear doors
  2. Wider doorways
  3. An elevator
  4. Grab handles around the baths and showers
  5. Invalid access bathtubs

Each of these 5 projects will be managed by a project manager and managed as separate projects.  I will take responsibility for the whole program, and at the end of the 3-year program, I will apply to the local authorities to get the house handicap access approved.  I know I’ve been successful when I get the approval.

So I have a Portfolio Investment Model for my house, one major Program (Handicap Access) and 5 home improvement projects that all have to be successful for the Program to succeed.  Also, there will be dependencies between the projects (I need to get the ramps constructed first to make it easier for the builders to do the inside jobs).

Common Trap #1 – Ignoring the Power of Program Management

I am fully convinced that these 3 disciplines – Project Management, Program Management and Portfolio Management build on each other – each is a foundational disciple for the next.  If you have lousy or inconsistent Project Management, you’ll never have effective Program Management or Portfolio Management.

The first trap I see many companies fall into is that they focus on Project Management and Portfolio Management, and forgo Program Management because they don’t really understand it!  Then they wonder why Portfolio Management never really gains traction or helps to elevate the business value of IT investments.  The Portfolio they end up with a simply a laundry list of projects. In my simple analogy, I’ve recognized that the 5 Handicap Access Projects are connected – I can’t gain the full benefit of the Program until all 5 Projects are completed.  Also, by recognizing they are interdependent, I ensure that they projects work together to reach my program goal.  You can’t easily connect Projects to a Portfolio without the intermediate abstraction of Programs.

Common Trap #2 – Portfolio Management as a ‘Bottom-up” Exercise

The second common trap is that people “back into” their portfolio model bottom-up.  Rather than take a position that they will budget 40% (using my analogy) of their total investment in “improvements”, they derive that number by summing up all their improvement projects.  That is hardly strategic!  They have failed to establish a portfolio strategy.  It would be like randomly picking stocks, bonds, precious metals, and so on, and figuring out what your portfolio model is, rather than saying, “At my life stage I want a conservative portfolio of 80% bonds and cash equivalents, and 20% mostly domestic stocks.”

Common Trap #3 – Failing to Engage Business Leaders in Defining the Portfolio Model

The third common trap is failing to bring senior business executives into the strategic thinking that leads to a Portfolio Model.  If business executives recognize that 80%, say, of the IT budget is consumed by day-to-day operational costs, and that only 20% of investment going to new capability, they may get quite interested in tackling the operational cost problem if it can free up investments in new capability.  And it is often the case that most of the cost drivers in operating IT are in the hands so the business executives.  Bringing them inside the tent and engaging them in deciding the right portfolio mix for the business strategy can be transformational!

 

Graphic courtesy of PM Study Circle

Related articles
Enhanced by Zemanta

Why Some Projects Should Be “Led,” Not “Managed”


I’ve posted before (many times!) about Business-IT Maturity, and the common “sticking points” that most IT organizations run into around the mid-point between low and high maturity.  (See, for example, here, here, and here, or enter “Sticking Point” into the search box.)

Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

Enhanced by Zemanta

 

The Accidental Project Manager


Some IT organizations invest a great deal in the processes and disciplines of Project Management.  As well they should – much of an IT Organization’s work is performed through projects.

Various approaches are deployed to bring consistency and effectiveness to Project Management disciplines – Centers of Excellence (CoE), Project (and Program and Portfolio) Management Offices (PMO), certifications (such as PMI), and so on.  But there’s a dirty little secret out there…

Many Projects Are Managed By “Amateurs”

By “amateurs,” I mean people who are operating outside the supposed disciplines, processes and standards of the PMO or CoE.  There are several reasons behind this:

  1. In some cases, it is simply a result of project work being deliberately flown ‘under the radar.’  I’ve consulted to IT shops where this is actually an effective way to get things done. It goes hand-in-hand with an “ask forgiveness, not permission” culture!
  2. Sometimes it is because the thing isn’t recognized as being a project until it is well underway – or maybe complete – or maybe never!  This is an issue that was recognized by the wonderful Jerry Weinberg in his early books on project management.
  3. In other cases, it is wanton disregard for the recommended (or even mandated) standards.  “These standards don’t apply to me.”  “They are too onerous for this particular project.”  “I don’t need them because I know what I’m doing.” And so on.
  4. In a few cases, it is sheer ignorance – not being aware that what you are doing IS project management, and would better be performed under the auspices of the rules and guidelines at play.
  5. One important driver of “Accidental Project Management” is inflexibility in the “official” Project Management methods.

Not All Projects Are Created Equal

To paraphrase Aldous Huxley, “Not all projects are created equal!”  Some deserve more rigor and discipline than others.  And some deserve different types of discipline.  For example, while many projects are most concerned with deliverables, budgets, resources and so on, planned against target dates, others deal with “softer” and more organic situations, where “emergence” is the key property and where planning by target date is unrealistic.

For example, a project that plans for, “30% of the IT organization will participate in the IT Strategy Wiki by July 31″ is not a valid planning approach.  Social activities work best through a “pull” approach – let’s identify the things that can be done to encourage and facilitate the “pull” and plan those.  The 30% participation may be a reasonable goal and outcome, but it is not a planning parameter in the sense of traditional project management.  To plan assuming that date will be reached is sheer guesswork, and anything else in the plan that depends upon this milestone is at risk.  I guess you call call the planning approach for these more emergent based needs, “Do while…” rather than the more deterministic, “Do until…”

Increasing Project Discipline Without Communism

So, what, if anything, can be done to reign in the Accidental Project Manager?

  1. First, decide if it matters.  Identify the real problems that loose project disciplines cause.  One problem may be that it’s the beginning of a slippery slope.  It sends a message that we “have standards and disciplines you should follow, but… (nod and a wink!) it’s ok if you choose not to follow them!  Another problem is that you may have bad projects – projects that suffer through not being well (or consistently) managed, or projects that should not be undertaken.  I often see a cause of waste and dysfunction in my clients in projects that should not be going on, rather than projects that are badly run.  A big problem is the implications ‘out of control’ projects have on resource management.  You just don’t really know what people are working on, and what availability they may have.
  2. Second, if you decide it does matter, determine why it is happening?  Don’t make a big deal of this – you may drive the behaviors underground.  Rather, do an informal poll – water cooler chats – ask people to ask people – try to get a sense of why people act outside the “official” practices.

Chances are you will find root causes to be:

  • Ignorance (lack of awareness and training)
  • Inflexibility in the “official” practices (‘sledgehammers to crack nuts,’ for example)
  • Lack of bandwidth in the PMO (“they just don’t have time to help me!”)
  • Poor “official” practices (“too bureaucratic, more designed for the benefit of the PMO than for those trying to manage projects!”)
Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 3


This picks up on Part 1 and Part 2 in this series on IT Organizational Clarity.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

  1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
  2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
  3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

Enhanced by Zemanta

Are Your Processes Setting You Free? Or Holding You Back?


Early in this blog’s life, I posted quite a bit on ‘sticking points‘ that IT organizations find about mid-way through the journey to high Business-IT Maturity.  Process discipline can be one of the quintessential such sticking points.  Process management can get you out of the mess of Low business-IT maturity to a mid-level, but simply cranking up the degree of rigor and discipline will prevent you from getting to high maturity.

Three Ways to Abuse Process Discipline

  1. Forgetting that the heart and soul of process thinking is Process Improvement.
  2. Process becomes a substitute for thinking, rather than an aid to it.
  3. Not everything lends itself to detailed work processes.

Let’s examine these.

Come Back Deming – All Is Forgiven!

When the likes of Deming and Juran began spreading the gospel of Process Thinking, they weren’t talking about creating a process and freezing it in concrete!  The ‘Deming Cycle‘ – Plan, Do, Check, Out – was all about continuous (and sometimes, discontinuous, as in process re-engineering) process improvement.  And yet many IT organizations somehow leave this aspect behind as they institutionalize worksteps, activities, deliverables and milestones.  People are encouraged (forced”) to follow the project management methodology or systems development life cycle, and punished for violations.  For a while, things improve – some process is generally better than no process!

But then people begin to realize that the process seems to get in the way – inhibits agility.  Intelligent choices are held victim to the process, and bureaucracy reigns.  To get past this sticking point, people need to understand, believe in and be passionate about process improvement.  Be it incremental, stepwise improvement or breakthrough re-engineering, the missing ingredient of continuous improvement is essential to getting the intelligence back into the work and non-value-adding activities out of the work – especially if these inhibit speed, agility or quality.  The trick is to throw out the ‘bathwater’ of blind rigor without throwing out the ‘baby’ of process management discipline.

Three Ways to ‘Standardize’ for Repeatability and Predictability

Many years ago, my esteemed colleague Roy Youngman was co-authoring a book with me (Development Effectiveness: Strategies for IS Organizational Transition) and pointed me to this great work by Henry Mintzberg.  If a goal is to make work consistent, repeatable, predictable and of high quality, there are three ‘degrees of freedom‘ that can be tackled – the tasks, the deliverables, or the people.  The degree to which you ‘standardize’ within this mix is a function of the nature and complexity of the work you are trying to achieve.

For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.

For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.

For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below tries to capture this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, think training and performance support.

Some Process Management Questions To Ponder

  • Are your IT processes holding you back – or setting you free?
  • Are they an aid to thinking, or a substitute for it?
  • Is it time to move past the blind discipline of mindless processes to a more context-sensitive and effective approach?
  • How often to your processes improve, and where is the impetus and insight for those improvements coming from?
  • How are process improvements recognized and rewarded?
  • Is it clear who owns ‘improvement’ for any given process?
  • Is it clear who owns the ‘services’ that are delivered by given processes?

Answers on a postcard, please!

Enhanced by Zemanta

Exploring an IT Operating Model for Enterprise 2.0 – Part 3: Process Management


In Part 1 of this series, I suggested that the implications of Enterprise 2.0 for the IT organization are dramatic.  I also suggested that the ways of designing and executing an IT Operating Model in a Web 2.0 context are quite different from traditional approaches.  In Part 2, I outlined the major elements of an IT Operating Model as being:

  • Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
  • Governance – how we make and sustain important decisions about IT.
  • Sourcing – how we select and manage the sourcing of our IT products and services.
  • Services – our portfolio of IT products and services.
  • Measurement – how we measure and monitor our performance.
  • Organization – how we structure and organize our IT capabilities.

In the next series of posts we will consider how these elements can be dramatically improved with Web 2.0 capabilities.

Web 2.0 and Process Management

Process Management, including all phases of process design, deployment, automation, including work flow and continuous improvement, are well-served by collaborative approaches and Web 2.0 tools.  With minor add-ons, SharePoint plus some creative use of Wikis works well for most aspects of process management.  Furthermore, once you are in a browser and on the web, you have access to a plethora of collaborative tools that are helpful when performing process management work, including project management, mind mapping, polling, voting, training and communicating, financial modeling, drawing, 3-D modeling, and so on.  Cheap, and in many cases free, these tools let you create a productive environment, or even a “process management toolkit” for reengineering your IT operating model.

Microsoft, in their “People-Ready Process” approach to Business Process Management argue (appropriately, in my opinion) that you don’t need to standardize on a single tool – the needs and preferences of analysts, process owners, architects, and so on, as well as the tools with which each may be familiar, will vary.  Also, most of these Web 2.0 tools are evolving rapidly, so focus more on the techniques and building the skills, while being prepared to switch or upgrade tools as the market allows.  (Obviously, you need to work closely with your collaboration managers and enterprise architects to ensure they are well informed about what you are doing, and that you don’t create any ‘unpleasant surprises’ for them or the IT operations environment!)

Graphic courtesy of Microsoft People-Ready Process: Collaborative Process Design

Not Just About IT Processes!

Note that while my primary intent and focus for this series of posts is using Web 2.0 approaches in the design and deployment of IT Operating Models for an Enterprise 2.0 world, the same approaches apply to Enterprise 2.0 business process management.  However, I generally feel that the IT organization is well served “doing unto themselves” before they go too far “doing unto others”!  This is a matter of both need (i.e., IT organizations need a healthy dose of collaborative process management!) and experience (i.e., IT organizations should gain some first hand experience in the approaches before they plunge into business process management 2.0!).

Not Just About Web 2.o Tools

As IT professionals, we inevitably gravitate towards the tools, but collaborative approaches bring so much more than useful tools.  I find that with collaboration, it is so much easier to follow agile methods – thereby delivering value sooner.  It also brings the issues of organizational and cultural change to the foreground.  It is an old cliche that “people don’t resist change – it’s being changed that they abhor!”  By bringing a broader swath of stakeholders into end-to-end process management, the challenges of process deployment, adoption and ongoing refinement are significantly reduced.  People are far more engaged in their processes, including their design, use and improvement.  Furthermore, the rapid, iterative methods afforded by such collaborative approaches also facilitate a “design for implementation” approach – helping eliminate design flaws up front, and to iron out kinks faster than traditional methods allow.

Tell us about your experiences with collaborative business process management.  What’s worked well for you?  What not so well?  What have been the benefits?  What have some of the impediments been?

Cartoon courtesy of Doug Savage, Savage Chickens

Reblog this post [with Zemanta]

We Picked the Wrong Tool!


How many times have you heard, “We picked the wrong tool!” when referring to a project management or portfolio management or just about any other kind of tool for the IT organization?  I’ve heard that many, many times over my 30 year consulting career.  So, it’s time for a couple of uncomfortable truths – expressed as “Merlyn’s Rules of IT Tools”:

  • Merlyn’s Rule #1:  You will always pick the ‘wrong’ tool.
  • Merlyn’s Rule #2:  If you focus on the process being automated or supported, and the management of organizational change, you will probably find you actually have the ‘right’ tool.
  • Merlyn’s Rule #3:  If you focus on the process and management of organizational change and still want a different tool, then switching to a new tool will be trivial.

The Cobbler’s Children

All IT people know the three rules above.  You would never allow technology to be applied to a business process without reengineering the process first.  And yet, when the “customer” is the IT organization, all the conventional and hard-earned wisdom goes out of the window and into the shredder!  I’d like to explore why this is, but frankly, I don’t know.  I guess it is a syndrome that all professions are prone to – hence the ancient proverb.

Image courtesy of USDA Agricultural Research Solution

Reblog this post [with Zemanta]

Deming’s 14 Points Revisited: Part 3


change leadershipThis post picks up on Part 1 and Part 2, and examines the second of Deming’s 14 Management Points. As I said in the first post, I believe Deming’s 14 Points have great resonance in today’s economy, even if his original language seems a little stilted in today’s world of Tweets and sound bites.

Let’s take his second point:

Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.”

When Deming mentions the “new philosophy” he is covering a huge swath of leadership principles that he developed over the years – in some respects, the embodiment of total quality, with a strong dose of Zen and Buddhist teachings.  An electrical engineer by training, a statistician by vocation, and very much a humanist at heart, Deming believed that management (especially from his US-based perspective) had lost its way.  He saw workers on the one hand be berated for productivity failures that were more to do with the processes management handed them, and on the other hand, be exhorted to “do it right the first time” by posters and tee shirts, without getting the tools and training they needed.  In other respects, the “new philosophy” is embodied in the 14 Points.

But there’s a hidden meaning in Deming’s 2nd Point – unless management adopts the changes they want to see, they shouldn’t expect the workers to do so. Unless these changes are adopted and recognized at all levels, they’re unlikely to succeed. i.e., Practice what you preach.  When we ask our organization to be rigorous with time recording, or adhering to the project methodology, management has to model the behaviors they require from their workers.  People will follow the walk, as they say, not the talk.  And if the talk and the work are inconsistent, management has lost its ability to lead change!

Image courtesy of Cathy A Price Leadership Coaching.

Reblog this post [with Zemanta]