Tuesday, August 04, 2009

Project Management - But we do Agile!,

In a current project it is interesting to hear the comments people make to defend their current practices. I have been involved in running out a project framework. The aim of which was to put some strucutre to the way people work to delivery the project.

Common statements I hear are, "This won't work with our business", "we are different to normal business", "This won't work with large project", "This won't work with small project" and the best to date is "We do adgile methodology".

Like always it was'nt until I thought more about it I was able to come back with a statement to squaure things off. But unfortunately 2 days had past and the meeting had well and truley finished.

Over the last 10-15 years I have come across many different way to manage projects. PMBOK and Prince2 just to name two. As a former software developer and software develpment manager Agile is a Methodology that I was aware of, but it is as far as I am aware a Software Development methodology based around iterative development, where requirements and solutions evolve through collaboratiion between self-organising corss functional teams. The Agile approach generally promotes a project management process that encourages frequent inspection and adaptation, a leadership philosopy that encourages teamwork, self-organsiation and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software and a business approach that aligns development with custoemr needs and company goals.

This is all great if you can hit those goals, the trouble is Adgile in this situation was being used as a defence. Don't get me wrong I have used Scrum and xpress in the past and when all things are going your way it works well. But in many situations I have rarely found anyone who is a true exponent of the process and it being used more as a defence so they don't have to move out of their comfort zone.

As far as I am concerned a project framework is a checks and balance to see that what has been requested has been delivered. It is designed for the business user and to start to move IT to a better alignment to business.

A project consist of a number of items:
1. We have a problem that requires a possible technology solutions
2. We have some inputs
3. We have some business rules to apply to those inputs
4. We need some outputs

The framework is designed to define, measure and check for delivery. The meeting the other day just showed more of what it is that IT is missing. Business Drives Business and IT provides the technology to give a return either as improvement in process or Return On Investment anything else is a waste of money and time. IT the clock is ticking and we need to rethink how we engage with buisness.

Wednesday, July 29, 2009

The business-quake has been, so where is IT today?

Traditional IT centric businesses are not coping nor are business. There needs to be a better way for IT. Business needs to become more agile and change is inevitable. Changes in technology, competition, governance and customer demands all need to work. This change will not stop or slow down and IT needs to lubricate the wheels of business. IT needs to provide the competitive advantage and meet the ever increasing demands on its level of service.

So much is riding on IT today that they need to shift from those bits, bytes and boxes to the provision of a Service Centric Business Model. This is a mind shift that IT and the business need to take, moving from the fragmented approach of the past to a more integrated and service drive model.

In this way IT will be better able to articulate their services and understand what it takes to deliver those services. So how does IT do this? Where do they start? They start with accepting that there has been a seismic change in business and how IT supports the business. Until IT and the business have come to this realisation they are stuck in the past and potentially have become victims of the quake. But if both IT and business have come to this realisation there is a change.

IT needs to accept their role in business is that of the steward and not the Lord of the Manor. This is a big step and crucial to the process and mind shift. Business has to take back its role and become the Lord of the Manor and provide the direction and demand. This can only happen with good communications and Governance. Because unless the business includes IT at the board table how they are going to know which way the ship is going and anticipate the challenges ahead.

Once the players have taken back their roles and the business has provided a map for the journey they can begin. IT needs to bring value and alignment to the business. This is done by defining the services needed by business to maximise its ability to respond to the market. Business is not longer interested in the bits, bytes and boxes. They are only interested in what they need to do to get the job done. IT needs to define their wears in those terms and forget about the bits and boxes when doing their work.

The demarcation is business need to work IT needs to provide those services and then maintain them to the agreed levels. IT has to provide value and their need to be a return to the business in a cost effective and efficient manner. The other role for IT is to identify all the business processes and define the best cost effective solutions to deliver those services. IT’s mantra should be to “Continually Improve Services”. Give the competitive advantage, utilise the latest technology but only if it is cost effective and efficient and provide value and a return to the business, either in productivity, money or both.

Tuesday, May 26, 2009

All Great Paintings Need Many Colours

So the journey continues, after 3 days of Service Support I now have a good appreciation of what a Cofiguration Management Database (CMDB) can provide. In its self it has some capabilities but when in concert with Incident, Problem, Change and Release Management it really startes to shine.

I am currently working on a piece of work where we are writing into the document the requirements of an incumbant to utilse ITIL practices. The document is still in draft and reference to having to provide the services of a CMDB were islands in the documents. After completing the 3 days I now fully appreciate that the power of the CMDB is the component parts that are connect to it.

When an Incident is rasied which indicates an interuption or reduction in service, the important part is its association to a Configuration Item (CI). This is where the picture starts and provides the colour to each CI. As an incident is processed and moved through the process the CI is constantly updated with the progress. At the completion of the Incident there will be more colours added from Problem Management, Change Management and Release Management. The end result could be quite a colourful picture, but the real depth comes with the time as more Incidents are submitted. Layer upon layer can be added of tone and colour. Like the old masters of art until you can see the full picutre and are able to appreciate all the colours.

Over time the CMDB becomes quite a powerful agent, providing trend details and information across all the CIs in the CMDB. This in turn then empowers the Service Desk to be more proactive in their goal to reduce Incidents and provide constant improvement over time.

Tuesday, May 05, 2009

The Evolution of IT Alignment

Businesses are going through an evolutionary period, especially in today’s market. Businesses have to face change at an ever increasing speed. The technology of business has had a massive impact. Its constant improvements have lead to much efficiency in businesses but at times cost dearly. We are hearing of the job losses and cuts but are they the best solutions. It provides an immediate cessation to money going out of the business. But are we throwing the baby out with the bath water?

More and more business are having to take a look at their businesses and how they utilise their resources. IT for a long time has been the black hole of business both in understanding and money. But in reality businesses needed to take control and look at the value that the technology was bringing to the business. In other words value for money, are we improving our processes, saving money or even making money with our technology decisions.

Alignment is the next stage, aligning the strategy of our technology to business, moving from “Reactive” to “Alignment”. Seeing that the business strategy and direction are deciding factors to our technology spend and direction. IT no longer can stand-alone in its decisions and direction it needs to provide real value to the business and business needs to drive the IT Vision. But alignment is not the only thing we need to do. The second part of alignment is building an agile business prepared to change as the business needs. This ability is brought about by having a sound architecture and Governance over IT. Our decisions in that architecture needs to provide the best outcomes but with the most flexible options. This is accomplished by having our solutions delivered in a tiered fashion, freeing the business from brands as the solution is provided to a model. In this way technology can change direction as much as the business. Business can take advantage of improvements as they appear, moving to the business drivers and not the technology companies’ drivers and directions.

Once the business and IT has then been aligned the next step in this evolution is collaboration. The business needs to evolve further to take advantage of technology and what it has to offer. Technology can have a high price, but it does have its advantages. It is the balance of business to technology that a good CIO brings to the table. Businesses need to utilise this resource and invite the CIO to the executive level to have input into the business and how it can maximise its technology even further. The CIO’s role is a conduit to the technology, their role is applying technology to business strategy but if they are not included in the planning the business is losing out.

So to complete this evolution to a collaborative and blended strategy businesses need to embrace technology, align their values and direction then maximise the understanding of what technology can do for the business based on those alignments and values.

Monday, May 04, 2009

Business need to admit IT mis-alignment before they can align

This point is critical both for the business and the executive in that buisness. In the ITIL book "Best Practices for Applicaiton Management" there is a phrase which articulates this perfectly.

"IT is not technology itself that supplies returns to a buisness,
but how technology is employed to meet business requirements."

Study by IBM and The Economist
The biggest issue is getting the buy-in by business to realise that there is a disjoint to how the business and IT need to work as one.
This alignment can be carried out in a number steps
  1. Identify the different applications used by the business
  2. look identify the diffeent busienss owners
  3. finally identify the customers both internal and external

From this exercise we can then start to build a map of the physical systems and the flow of data through those systems. This looks to be the foundation to then start to understand how the business is using the technology and from there I would see we can then identify the value to the business and then start to build an alignment map and strategy.

A business cannot realise value from its IT until it has been algined. This was argued in 1993 by Henderson and Venkatraman of Harvard Unitversity, any search for these names with IT alignement will find more details.

This article is more a question, I understand the need its just getting the common view point and how that is achieved.

Friday, May 01, 2009

Service Support a very good place to start

My journey begins with review and testing that review. Page one of the Service Support manual was where I started. Familiarising myself with all the Terminologies again, yes they help when you work with them day to day but we need to remember who we are talking to.
One of the biggest issues we need to understanding is change will need to happen at a cultural level and people will resist.

Implementing new processes in to an organisation we need to realise that not everyone will know what we mean when we refer to SLA or OLA. Some might but when we start to venture into CMDB and KER and all the rest of them we need to consider who we are talking with. The last thing we want is to alienate the very people we need to support and take on these processes.

In looking at way to improve my retention of reviewing the materials I started to look around for online resources. There are many and a simple search via Google will return many of them, but one I found to be very good. That was the site “ITIL Free Mock”. You will need to register and activate your account, but once that has been done you have access to a large variety of mock tests.

The website currently provides 569 questions to study for ITIL® certification version 2. The site hopes to have version 3 in the future. They don’t claim to be an official ITIL® website, they just provide a great tool to assist in the preparation of ITIL® exams. The best part I found was that you can see your performance as well as review your answers and understand where you went wrong.

The journey continues....

Thursday, April 30, 2009

My Journey to the land of ITIL

Today I had an interview to see if I met the criteria to attend an ITIL Masters Course. Good news I past but I am not sure that they knew I was carrying out my own interview, good news they too past.

In many ways doing this course and obtaining the certification is more I believe a validation of how I have always thought. Back in July 2005 I wrote a blog called "The Keys to your Mansion" it was about how decisions of technology needed to be taken further up the tree. That the value to business had to be taken into consideration and that IT should be considered a service to business. In many ways this is the culmination of my experiences and now putting it together with both my business and technical experiences I believe will help me in my journey.

Since then I have gained a far greater appreciation of where those decision should be taken. That IT is not its own entity but an intragal part of Business. It can no longer be seen in isolation but as a necessity of business. Business needs to own its busines and IT is its business. It provids the connectivitiy to the digital age we live in, but it can't drive business. Like all buisness it has to be part of that value chain in the delivery of services. It is in aligning the business strategy and values to IT that will bring around more prosperity. ITIL I believe is just one of those tools we can use.

Over the next few blogs I am going to write about my journey in obtaining and hopfully applying the knowledge I gain from this course. I hope any reader will start to see the development of my understanding from the knowledged I gain. Hopfully my future blogs will become a better articulation of that knowledge and application into an organisation. ITIL and its application is a process of continual improvement. These blogs should represent that continual improvement in my knowledge and understanding.

The course I am doing is with the Conan Group in Western Australia. From what I have experienced to date this company has a passion about ITIL I believe is infectious. I am looking forward to being infected with more of that same passion. The important part is you not only have to walk the talk, but you need a swagger. I believe I have found that in this company and I look forward to my journey.

Tuesday, March 31, 2009

Securing the Layers of Web Development

When building up a Web site you should consider all layers for security.

When building a commercial Web site, security is one of the most important issues to consider. A good understanding of the layers used in the delivery of a solution, as well as knowledge of the types of threats will always help. When you look at any web development, these layers are: the foundation, the physical computers, the network, operating systems, applications, the development and underlying code.

Understanding where the weakest link is in these layers will help the business address those weaknesses. The hardware and operating systems are found at the base of these layers. The security around these are managed with patches for both firmware and software updates.

The next layer of threat is how and where you store your data. This will involves both the software and the hardware arrangements. Looking at how the data can be accessed and who or what accesses it can be important. A good practice is to ensure that your data is not accessible by the web.  Make sure that it can only be accessed by a call from you application layer with a trusted internal link.  These applications need to be maintained with their respective updates, fixes and patch releases. With patches and updates, implementation should always be after extensive testing and understanding of the benefits.

Another layer contains the web servers and application frameworks.  Many of the modern development languages now have well-defined frameworks that provide some of the tools to building better solutions.

The final and weakest layer is the flaws that arise from badly developed business logic and known vulnerabilities. There are many sites on the web warning and advising developers of these vulnerabilities and their proposed fixes and solutions.

When engaging this area of development, you often need someone with experience in this field to help. The web provides many examples of people, consultants, companies, products and services to aid in this field. The more astute the average hacker becomes, the more we need to be mindful of this issue and seek the relevant security expert.

In a previous development project undertaken by my company, one member of the staff did not agree with my choice of development environments.  They hacked a commercial web site which was using a similar environment. By doing so, they illustrated that it was their knowledge of the vulnerabilities of the underlying web services and not my choice of development environments.

This example highlights the need for securing all layers and not just the development layer of the project. Security failures happen for many reasons. They could be caused by hackers, disgruntled employees or a lack of knowledge of the environment.

There are no totally secure systems. The only way to guarantee total security is to unplug from the net. Of course, that is not practical. You simply have to be cognizant of the layers of dependencies and manage the risk.

This article has been published on to sites around the world.

  1. eucommerz.com
  2. emqus.com