ProjectExperience

IT Service Management (ITSM) is a set of capabilities that was born from the knowledge and expertise of implementing the principles of delivery value from the Information Technology Infrastructure Library (ITIL) framework. An enterprise that is majorly dependent to its Enterprise IT capabilities continue to acquire technologies that will help it manage I.T. specially when an outage is brought by an incident or a problem. The need for an ITSM tool usually comes out when a software or hardware goes to production use. We call this phase in ITIL Service Operation. Within that phase, we build our Operational Support and Analysis capabilities such as event management, incident management (includes security incidents), problem management, change management, and request management. Most tools that have been produced focused around incident, problem and change management. Many did not take the step to mature and look at all the phases of ITSM and their associated functional capabilities.

Image above courtesy of The ITSM Review.

@Stephen Mann wrote a blog identifying some drivers as to why a new tool is/was needed or the current tool needs to be replaced. He requested the readers to chime in and vote on the identified drivers to help solidify the theory as to reasons ITSM tools are replaced. BTW, he initially listed twenty-five (25) potential drivers. The community help whittle down the list to ten (10). His findings indicated the following:

  1. Tool dissatisfaction related to: ITIL-alignment, usability, manual activity, flexibility, or customization. 18%
  2. Old tool failed to deliver the expected benefits. 17%
  3. Tool was end-of-life or simply outdated/a homegrown ITSM tool was no longer workable. 12%
  4. Corporate cloud strategy/a larger transformation project/senior employee dictated it. 10%
  5. New ITSM process adoption required a new tool, including enterprise service management support. 10%
  6. Excessive costs related to maintenance fees, admin effort, or upgrading the existing tool. 10%
  7. Other. 9%
  8. Dissatisfaction with vendor support and/or relationship. 5%
  9. Multiple service desk and tool rationalization project. 5%
  10. Liked the look of an alternative tool/convincing vendor marketing/industry hype. 4%

I highlighted the four (4) drivers that resonated to me as a technology decision-maker. The above high-lighted drivers are the items that a tool should be able to satisfy to enable I.T. to show its value to the business. Having this criteria satisfied will allow I.T. to change the business perspective of I.T.; that it is only a cost center. It can now start claiming that it is also a profit center of the enterprise.

What do you think?

The technology and solution providers has been in this quest and journey of helping or making enterprises become agile. Most of the conversations I have had with management teams will always bring up a topic to a certain degree that refers to being agile or become more agile. Just like the words innovation and DevOps, the word agility is a loaded terminology. Every organization will look at this differently based on its organizational or enterprise context. Speed of delivery has always been something that management or the executive team wants to have due to market and economic conditions. The challenge is how does one implement agility in an enterprise and not just the I.T. organization.

The usual approach is to start with I.T. particularly when building a technology solution; software and/or infrastructure. However, starting with I.T. does not always mean that agile adoption or agile transformation will work and add value to the organization. It is all about the adoption and transformation context. Most of the time the agile transformation or adoption is challenged if not completely failing. There was even an article written here in LinkedIn titled “Agile does NOT work!“. I agree with some of the frustrations written in the article. However, this tells me that the people particularly the management/leadership did not really support the initiative to make sure it works and adds value to the enterprise. I always say this to anyone I speak with. When you choose to take the path into enterprise agility, you don’t just do cowboy coding. You don’t forget the practices that makes a product fit for use and fit for purpose. The trouble most of the time is that the people almost always fall into the trap of “just doing it”. Product release (software or otherwise) should always be based on the principles of fit for use and fit for purpose that is delivered faster to meet business and market demand. Adrian Wible wrote some sample considerations when working towards enterprise agility. Below is his sample list :

  • Legacy system dependencies
  • Vendor dependencies
  • Disparate technologies requiring different skill sets, resulting in divided teams—e.g., mainframe versus Java, mobile versus web
  • Geographical separation of talent (different time zones, or even just different floors)
  • Coordination among software, firmware, and hardware teams
  • Lack of automated tests (I think this is one important key constraint in achieving agility).

Adrian further talked about potential agile maturity performance indicators to consider when transforming into an agile enterprise or at the minimum an agile I.T. They are as follows:

  1. Agile requirements maturity. What to build.
  2. Engineering practice maturity. How to build.
  3. Testing practice maturity. How and what to validate.
  4. Deployment maturity. How to release.

I thought some of the contents in his article would help the reader take a step back and re-consider the approach they are taking towards enterprise agility.

What’s your thought?

Cloud migration and transformation is a topic that has been in the minds of many IT shops but were unsure how to move forward.  Many data centers are probably thinking, I will just move my application from my server and run it in a virtual machine in AWS, IBM Softwlayer, Google Compute, or Microsoft Azure.  However, the movement to the cloud computing space is not as easy as you might think.  I wrote papers on cloud adoption strategy and my consumers saw it as a simple exercise and not different than what we have in the data center or computer room.    I pretty much said we need to be focused, methodical and disciplined in migrating to a cloud computing environment.  It is really interesting to mention that Netflix has led the industry in this space after it became a leading streaming video service provider.  The Netflix blog told its story and a piece of its cloud migration journey.

There are some lessons learned from this journey and I will be quoting what @Noel Wurst of Cloud Zone wrote in his article.  They are as follows:

  1. This is not a sprint.  It is a marathon.  You will not to migrate all of your business or mission-critical applications to the cloud in a single year.
  2. You need to think through your current architecture and re-design the architecture your technology and processes.  Moving to the cloud is more than just moving the application,  processes and financial models need to change.
  3. Garbage in-Garbage out.  This is not only applicable to data but to applications and processes as well.  Moving applications in a lift and drop mode to the cloud moves all of the existing problems along with them.  I actually told a former colleague while talking to them about DevOps and automation that we don’t just automate things.  We have to think through all the elements involve because if we don’t, we are just automating our existing problems.

Moreover, I have heard of this comment before, “We are not Netflix”.  Yes, that is true but you can use the good practices learned from those experiences to execute your own cloud migration and transformation initiative.

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.

Software is becoming the main business lever to growth and innovation.  This trend speaks not only of the application but also of infrastructure deployment.    This created an appetite for enterprises to adopt Agile and DevOps practices to build and deploy software faster and potentially with the desired quality of the project to ensure that the software product is not only fit for use but also fit for purpose.  The goal is to enable the enterprise to meet market demands.  However, despite all the success stories in the use and adoption of agile practices, larger organizations are finding it challenging to compete in the market place.  I have encountered organizations looking for scrum masters to add to their team to help move agility in IT.  However, if you would look at these larger organizations, they still are having problems with their software deployment velocity and quality.

I think that the enterprise’s adoption of Agile or DevOps should not only be a grassroot effort but also an executive level commitment.  The executives and management need to understand that this practice is an organizational change and this requires a clear understanding that the adoption is driven by the business objectives.  I have always presented to my potential employers that I am a business-driven leader because that is what I do.  I first try to understand the business goals to understand why a PMO for example is needed by the organization or why DevOps adoption would be a valuable investment for the enterprise.  Since this is an organizational change, I would tend to say that this leads to understanding the longer term goals from a transformation perspective.  The executives should practice the ITIL continuous service improvement mindset to effectively engage the organization in this journey.    The executives and management should support the new delivery model of thinly slicing work and delivering business value based on that slice of work compared to a plan-driven model where you try to forecast when the project will be completed.  This is a known mindset change.

Once this is in place, the enterprise would obviously try to invest in automation represented by the DevOps practice we have been hearing recently.  This model of integrating working codes into the main software pipeline is a big challenge.  I would caution you on this because as IT professionals we have the tendency to just look at “tools” or technology and skip the process and practice part of the venture.   This will require cultural shifts in the IT functional groups.  Adopting DevOps and Agile practices cannot be done in a short time.  Like the old saying goes, “we did not get to this mess in a day”.  It was a journey and therefore it requires patience to get through this agile journey as well.

Scaling Agile and DevOps within the IT team would not be easy specially when they have been operating in a functional model and does not look at the IT value from an end-to-end service model.  We need to have a good understanding of the Agile and DevOps principles and accept that this is a solution to the shortcoming of the traditional work practices we have in our environment.  Change management is one of the areas that will be impacted by this new work new model.  When doing Agile, I would encourage that you look at the business results you are hoping to achieve and not focus on just the “team”.   The other area that will seriously be affected by this is the project portfolio management domain.  It has to shift from looking at projects to looking at enterprise business backlogs that is aiming to give business value or increase revenue through the incremental and iterative delivery of these backlog items.  I am not saying that you will have a panacea but at least you will have better alternatives to the impediments you currently have at hand.

What do you think?

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

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.