A rare sight

A rare sight

Many of you will have encountered some of the following decisions being casually made by top management:

• The budget rules are changed (usely sharpened)
  
• (part of) department x is merged with department y


• Some activities and positions are made obsolete of outsourced


• The management structure is reorganized


• Employees have to report differently to their manage

What I find so odd is that project management is not used to manage these types of internal changes.

Project management is applied whenever an external client is involved but we can’t be bothered to adopt a structured approach when we re-organize our internal workings.

Changing your internal organization is like throwing a pebble in a pond. It has more implications than one person (i.e. the manager) can oversee at first sight, the ripples can go through the entire pond.

The accountability for the entire set of implications must lie with the manager taking the decision but why not assign a single project manager to:
- make an overall impact analysis on the entire organization
- take on the risks and challenges while executing the change
- follow up if the original goal has been achieved
- propose any needed fine tuning on the original decision

An (IT) strategy is no good if it's a one shot guess at the future and is only top down driven.

An (IT) strategy is no good if it's a one shot guess at the future and is only top down driven.

A realistic view on an IT strategy will show that it is the consolidation of three elements:

• the IT strategy per business unit (bottom up & continuously applied and reviewed on basis of feedback)



• the IT strategy on corporate level (top down & continuously applied and reviewed on basis of feedback)



• the IT strategy on new technological developmemts (consistently applied and reviewed on basis of feedback)

An IT department that wants to grow into a strategic business advisor can be helped by running IT as a "businesses within a business" (BWB)

The BWB concept is not identical to outsourcing or IT as a profit center but is sound entrepreneurship consisting of :

• knowing your customer, treating customers as clients that "buy" from you (documented in "Internal contracts")


• defining a value proposition by looking up into the value chain of your customers


• doing SWOT analysis (competition is outsourcing and decentralisation)


• delivering the value at a minimal cost (building and maintaining partnerships & focusing on core activities)
  
• judicious risk-taking & innovation


• embracing competitiveness, strategies, and growth opportunities.
  

The roadmap to transform IT department into a BWB consists of:

1. IT managers have defined their lines of business (e.g. subject matter experts, coordinating, quality assurance, etc.)

2. Developing and marketing a catalog of an organization's products and services (to clarify clients' expectations and staff's accountabilities)

3. establishing clear internal contracts, pre-requisite to a consistent practice of internal contracting is a culture of empowerment and accountability, this implies:

• a PMO that doesn't disempower the IT resource owners but takes up the role of facilitor and QA


• a culture of internal contracting supported by top IT and Business management

The Implementation of the IT strategy is done mainly through the process of demand and portfolio management and the needed IT governance. Each demand / request must be analysed to define what the customer is buying and to identify the prime contractor who's in the business of selling it.

Improving the ROI on IT by reducing the cost of learning.

Translation in English will shortly follow

Investeringen in Software (en indirecte investeringen zoals opleiding) hebben geen restwaarde eenmaal het zover komt dat de betreffende software applicatie vervangen moet worden.

Daarom is het belangrijk om:
1. de initiële investeringskost te minimaliseren voor een gegeven scope en kwaliteit.
2. scherp te sturen op de continuïteitsverwachting van de software (levensduur, aanpasbaarheid)

Op beide punten wringt het schoentje ten voeten uit. Vele projecten veroorzaken meer kapitaalvernietiging dan noodzakelijk.

Wat betreft de projectkost of de initiële investeringskost.

Elk project heeft een initiële opstart kost omdat projecten per definitie van tijdelijke en unieke aard zijn. Ik verwijs naar de metafoor van het ontwerpen en bouwen van een fabriek alvorens de fabriek kan gebruikt worden (om ‘software te maken’).

Echt vermijden kan je deze kosten dus niet, maar minimaliseren wel, natuurlijk.

Zonder expliciet beleid voor ‘industrialisatie’ van de software projecten vindt elk projectteam het wiel uit met alle aanvullende leerkosten van dien. De wet van de schaalvoordelen en de leereffecten wordt niet opgepakt overheen projecten. Industrialisatie moet leiden tot minimale opstartkosten en wel op 3 vlakken:
- functioneel / inhoudelijk
- technisch
- planning en controle

Leereffecten op het functioneel inhoudelijk aspect is moeilijk te realiseren omdat een project veelal gericht is op verandering (een uitzondering is de zuivere herbouw).

Leereffecten op technisch en planning&controle vlak kunnen makkelijk gerealiseerd worden door eenzelfde team mensen meer dan 1x met dezelfde technologie en processen te laten werken. Impliciet wordt hier verondersteld dat de IT afdeling zich moet organiseren naar specialisme in bepaalde competenties i.p.v. een organisatie waarbij elke werknemer aangespoord wordt tot generalisme.

Het risico van te grote leerkosten ligt in vele gevallen bij de klant. IT leveranciers hebben immers meer belang bij het ‘wegzetten’ van resources (oftwel factuurbaar houden van hun consultants) dan met het reduceren van de leereffecten voor de klant. Dat is zeker het geval bij Time&Material contracten maar ook bij Fixed Price contracten is de business value van het eindresultaat het kind van de rekening.

Projecten die ‘nieuwe technologieën’ implementeren zijn naar mijn ervaring en kunde gevoelig voor grote leercurve (ten koste van de klant). Voorbeelden uit mijn eigen ervaring zijn: Business intelligence, SOA, Sharepoint 2007.

Wat betreft de continuïteitsverwachting van de software .

Continuïteitsverwachting is de verwachting over de economische levensduur van het project. De levensduur van een systeem wordt verlengd door lage kosten voor software aanpassingen en stabiliteit in de kosten doorheen de tijd.

Langdurig gebruik van eenzelfde systeem vormt in de regel een solide basis voor positief rendement op de initiële investering.

Er is een duidelijke “trade off” tussen de initiële project kost en de levensduur van het systeem. (een systeem toekomstvast maken heeft ook zijn prijskaartje). De project kost weegt meestal zwaarder door in de keuze voor een IT leverancier dan de toekomstvastheid.

TIPS:

• Zowel in het geval van pakket- als maat software heeft de klant belang bij een stabiele relatie met de leverancier.


• Vraag als klant harde garanties voor tenminste 5 jaar actief onderhoud aan een afgesproken kost per eenheid werk en accepteer geen offerte waar de hoofdlijnen van de doorgroei naar de opvolgende pakketversie ontbreken.


• Bereken als klant de Total Cost of Ownership (TCO) en kijk kritisch naar de onderhoudskosten en levensduur van het systeem.

Project failures, revisited

To start off I would like to give a few facts on software projects, derived from my own observation in the past 7 years as an IT project manager:

* In many a software project the only discipline that has more than 1 person is the development team
* The development team is the only team directly producing the end product
* Development takes the biggest % of hours and cost of the project (on average 55%)

In a previous post I have already mentioned two general causes on project failure i.e. people are not robots and doing things for the first time is notoriously difficult.

Since the above aspects are hard to avoid in the real world, I have been looking deeper into these 2 factors to discover some concrete aspects that can be controlled.

A logical conclusion from the above mentioned facts is that, when trying to control a project, the most urgent question to be asked & answered is "what has to be done before the development team can start producing at fast rate".

I want to put in perspective the usual culprits of project failure as Well documented by the Standish research Group:
* End user involvement
* Backing of the executive management
* Quality of specifications
* Expectation management

Indeed, I have rarely seen a project where the lack of requirements or specifications are the sole or main cause of failure. In most projects the main goal is reasonably clear. The fact that project success requires not just having the cake but having a cake with a red cherry on top, I just mention here for the sake of being complete.

Let me get back to my statement that more focus should be put on the development.

To get to a point where one can produce at a fast and steady rate you need to build a production facility first, yes?

So to get a software application at a reasonable fast rate you need first to design and build a factory that spits out lines of code. Have you ever seen a factory being designed & build and producing end products from the first day that construction starts??

So pay respect to this first important step "building and testing the factory", before embarking on wishful planning for releasing code fast.

The RUP methodology calls this the Elaboration phase.

This phase is very critical and elusive and determines for 90% whether the project will still have time, money and the desire of the stakeholders to have its cherry or even finish it.

Following the above, I give you some important causes of project failure (again derived from my own observation):
* a difficult decision making process on a complex architecture with many external interfaces
* a considerable sized project (starting from 100 function points) (implied here is a lot of work to build the backbone of the system)
* the use of tooling or techniques that just been invented and still has growing pains
* resources that lack experience (but usually not the interest) in the tooling or techniques being used

Expect a slippery slide for your budget and timeplanning when these statement are made by your architect and other team members:
* it is nice because we can use the latest tooling and learn a lot
* there is a part that requires the new tooling but it's not going to be much
* a lot needs to be decided still but we cannot plan too much in advance or into much detail.
* its not useful to invest in a detailed work breakdown for building the architecture, that will come along when the project advances

In many cases the gloomy fate of the project is even more exacerbated due to lack of recognition for the need for a technical team lead that micro manages the developers.

For example, in the designing and building the factory phase many ideas come from each developer on how to best do things, these ideas have to be consolidated and synchronized through coding techniques. If not done (properly) the factory will be dysfunctional for sure and lead to an overrun on the elaboration phase.

In summary.

Consider well beforehand the technical choices that have been made by your teammembers or by your supplier. Be realistic about the impact of the choices on the cost of the learning curve i.e. the likely overrun in the elaboration phase.

Be also aware that many suppliers underestimate or are not aware of the cost of the learning curve.

So the best thing you can do as a customer embarking on a new technology project (e.g. SOA, Business intelligence) is to ensure that your team or supplier is providing a pool of resources that have already made it through the learning curve.

The Role of Information Management

Click the image for a closer look.

The above figure is a visual representation of my view on the role of the Information Management department, more specific in relation to the IT department, the business departments and the clients of the organization.