Archive for the ‘Uncategorized’ Category

The Problems ITIL Solve

I encountered a good article on the subject written by @Dan McCarthy. In the second paragraph of the article, I read something that resonated to my personal experience. I was about to do a presentation to the CIO and I was told by some of the folks in the organization not to use the acronym ITIL. I was speechless because my talk will be revolving around the value of ITIL if the IT organization adopts the practices to improve the value of IT. Dan’s paper quoted this, “Whatever you do, don’t mention ITIL”. This reminded me of another organization I know who is ramping up their project management resources and I was given a word by one of my friends who consulted with this organization that when I get to speak to their management team, don’t use the words “Project Management”. I was told to call the practice anything but not project management. There is some semblance to ITIL and Project Management. These two follow a certain protocol or life-cycle in delivering their services to the customer.

Similar to many organizations that tried to implement a project life-cycle or methodology using the PMBOK as a guide, the ITIL framework suffered negative perception. Dan mentioned in his article that ITIL is too bureaucratic, too difficult, too expensive, too complex, too restrictive, slows us down, and most recent one is that it is no longer relevant. This last reason for not adopting ITIL is entirely misleading. Pundits say that ITIL is not longer relevant due to the growth of cloud computing adoption in the SaaS, PaaS, and IaaS space at least. You have heard and read articles written about ITIL being outdated due to the DevOps practices currently in play and all other modern developments in the IT space such as the IoT. As you have read, most of the content I mentioned are all negatives. No one attempts to write the value ITIL gives to the enterprise. No one takes the time to talk about the problems ITIL helps solve. I would encourage you to read the article Dan wrote as he highlighted two areas where ITIL helps solve problems; problems internal to IT and problems in the business domain. Below is a quote of some of problems highlighted by Dan. In my humble opinion, these can be used as critical success factors when rolling out ITIL-based capabilities.

“Internal IT problems:

  • How can we all get on the same page, speaking the same language, so that we can be more effective?
  • Our processes are incredibly complex. It’s hard to see where they interact. We need to make their interactions clearer.
  • What does it mean for the IT organization “to do better”?
  • We need to be able to manage our interactions with the business across the whole IT lifecycle.
  • We need to be able to explain what value we give to the business. In general, answers like “We manage 1,000 widgets” don’t work – we need to talk about the services we provide in a more meaningful way.
  • How can we know if our investments have a reasonable return?
  • How can we plan for future business demand?
  • How can we deliver changes effectively and efficiently without tying ourselves to a single change framework?
  • When things go wrong, how can we minimize the negative impacts?

Business problems:

  • We want to invest in IT. We see its value for the organization, but we want someone else to manage the technical details effectively.
  • We want to invest in IT. We see its value for the organization, but we want someone else to manage the detailed risks involved in it.
  • We want IT to deliver business changes quickly and reliably.
  • We want to know if we could get a better, faster, and risk-optimized return on our investments in IT.
  • When things go wrong, we want negative impacts minimized.

The above is not the whole list Dan identified in his article. What is compelling is that we can have a crucial conversation with our stakeholders and tell them that ITIL can be a key problem solving feature of the Enterprise.


Infrastructure Technology Information Library

I have taken the time to be better as a practitioner of the infrastructure technology information library (ITIL) framework.  I did this because I believe this is one of those frameworks like the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBoK) that gives practitioners baseline mechanism to deliver quality outcomes.  In the case of ITIL, it was created to help improve the processes and work efforts we do in delivering IT services at the minimum and deliver business value; stable quality IT service.  I think this is a way for IT to show the business that IT is not just a cost center but a partner in generating the revenue the business is aiming for.    However, I noticed that many executives does not believe in the ITIL framework.  It is seen as confusing probably.  Think about the main phases of ITIL or I would otherwise say IT service management (ITSM).

You have the Service Strategy, Service Design, Service Transition, Service Operation and Continuous Service Improvement.  Inside each phases are processes that we have to understand.  Take a look at these fundamental items in each of the phases.

Service Strategy.  You have five processes in this phase.  They are as follows:

  1. Service Portfolio Management
  2. Financial Management
  3. Demand Management
  4. Business Relationship Management
  5. Strategy Management

Service Design.  You have eight processes in this phase.  They are as follows:

  1. Design Coordination
  2. Service Level Management
  3. Service Catalog Management
  4. Capacity Management
  5. Availability Management
  6. IT Service Continuity Management
  7. Information Security Management aka IT Security
  8. Supplier Management aka Vendor Management

Service Transition.  You have five processes in this phase.  They are as follows:

  1. Change Management
  2. Service Asset ad Configuration Management
  3. Transition Planning and Support
  4. Release and Deployment Management
  5. Knowledge Management

Service Operation.  You have seven processes in this phase with two IT functions.  They are as follows:

  1. Service Desk Function
  2. Technical Management Function
  3. Applications Management
  4. IT Operations Management
  5. Incident Management
  6. Problem Management
  7. Event Management
  8. Request Fulfillment
  9. Access Management

Continual Service Improvement (CSI).  This phase is really the best part because you would need to go through another cycle where ITIL showed the 7-Step Improvement Model.  Of course, every organization will need to adapt this to their own CSI model.

If you intend to learn the above in detail you will need to get the 5 volumes of ITIL books.  However, @ServiceNow created a simple paper that will help give a layman’s understanding to these ITIL aka ITSM concepts.  I would refer you to check out the paper as you will find it helpful.  ITIL is not only applicable to IT organizations but also to other organizations that provide services and this is what you will see in the ServiceNow paper.

DevOps for Systems of Record – A new hope (Preview of DOES talk)

Source: DevOps for Systems of Record – A new hope (Preview of DOES talk)

Project or Program Success: What Matters

I have been a practitioner of project management for a while.  I was attracted to it because of the opportunity to work with smart and intelligent people that creates a product and delivers value to the organization.  Often times, I would encounter organizations whose perspective of project management is simply having a list of tasks that need to be done by a mandated timeline.  I have questioned this work model in every conversation I will have with folks.  I thought is this project management or simply just being a task master.  I believe it does not take a lot to be a task master specially when you use the power of coercion to get a job done.

I have tried my best in my practice to start any project I am involve with identifying the scope of work that makes up the product and estimating time.  Often times, I will get an order that says I need this project done by a specific date.  I would ask my stakeholder what is the business driver for this.  I will ask who is our sponsor so that we can manage the work and manage expectations properly specially when the driving constraint is schedule.  Many a times, I would see projects executing as soon as the executives said get this job done by this time.  I still have to meet an executive who will stay rational when push comes to shove.  Project driven by this kind of pressure usually under perform.  It is a hidden cost to the project that is not highlighted.  No ones pays attention to the process of estimating work to manage and mitigate schedule risks.  Most of the time you will see a PM under pressure who would start building a project schedule by himself with no or little project analysis and definition.

What do we normally do when we miss a “promised” delivery period?  I would assume many can come up with various reasons in and out of the project team’s circle.  I probably would say start with a strong leadership and a determined goal of improving the culture of “just do it”.  Project stakeholders and sponsors should be made aware and hopefully get them to emphasize the value of accurate estimates.  Our estimates should improve one project after the other and management/leadership should reward such improvements.

One thing that I have promoted is the PM fundamental of creating a work breakdown structure (WBS).  I don’t see any project team that does this work anymore.  However, this is one of the ways we can improve our estimates; by creating a WBS.  The WBS helps visualize work packages or backlogs that will make up the product the project should deliver that gives value to the business and meets the customer needs.  The WBS enables us to define work better and properly I hope.

What should be the next step in the cycle when you choose to practice the creation of WBS in your projects.  I think you need to have the project team members involve in identifying the work package items and let them provide the estimates.  This is a another fundamental PM practice.  The project team members knows their availability and the work that needs to be done.  Therefore they are in the best position to provide an accurate estimate and a not guestimate if it is only one person creating that project schedule and putting estimates himself.  Estimates are estimates and should be treated as such.  Project managers and executives should be honest to the stakeholders when the estimates have to change.  Again this is in the interest of managing expectation and mitigating project conflicts.

You have heard how the agile techniques have help projects deliver faster.  I say this is not different in project estimating.  BTW, you need to have a method for estimating.  In agile, they use planning poker.  I would again go back to another PM fundamental in estimating which is the 3-point estimating technique in case you don’t have a way to use analogous estimating method.

More importantly, always account for schedule risks specially those driven by the unknown unknowns.  You need to create contingencies both in your schedule and budget.  This is also your opportunity to validate assumptions to help you better understand project risks.

BTW, have a method of tracking effort and progress.  Your team will be loaded with work that would distract them from doing project work.  It is important that you have a mechanism to identify potential timeline issues before the schedule gets impacted.  I use the earned schedule method on plan-driven projects.  In agile methods, I use the backlog, release and sprint planning to understand project performance through either the burn up or down charts.

In the end, you need to have a method of ensuring that you can meet the schedule goal at the minimum and deliver value as early as possible to the business.

#DevOps – defining Devops – it’s a Recipe not a Blueprint

Now this is a good short take on DevOps. It indeed a recipe.


There have been some great posts recently regarding the difficulting in defining DevOps e.g and following on from that

My view is that some of the confusion, and the multiplicity of opinions about what DevOps is, comes about because people are using the wrong cognitive frame when looking at DevOps, and maybe a bit of re-framing is in order.

Firstly, a bit of background. In The Blind Watchmaker (1986, pp. 295-296) Richard Dawkins explains that DNA is like a recipe, not a blueprint. You can’t take a slice of cake and then pull up the “cake engineering blueprint” and point to the section that specifies that part of the cake (as opposed to comparing a car or plane part to a blueprint, for example). You have a recipe… but there isn’t a one-to-one correspondence between the recipe and the cake.

“A recipe in a cookery book is not…

View original post 318 more words

Gene Kim and Red Hat IT Part 4: DevOps Successes and Failures

Gene Kim and Red Hat IT Part 3: A DevOps Implementation Strategy