Realistic expectations

•1/4 of what you wish for will deliver the exact opposite
•1/4 of what you wish for will have no result
•1/4 of what you wish for will be realized only by half
•The remaining wishes will fully be realised on the condition that you ignore all of the above and believe in your goals 100%

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.

The 'new' organizational effectiveness

Any enterprise is organized or divided around hierarchy and specialisation.

Departments are increasingly getting profit loss responsibility, employees are increasingly measured by their KPI's (Key Performance Indicators).

These are good practices in the way that they add control per single entity but are counter productive to cooperation and learning across organisational boundaries.

In many of the companies I have worked as a project manager I notice:

• the absence of a feedback loop in any decision making process
• the absence of cross department and cross enterprise cooperation
• the absence of implementing lessons learned

It is rare to find companies that perform well on these practices because they hit the wall of the hierarchy and specialisation.

Why do I think it’s a relevant issue?

1. Because cooperation (across disciplines, departments and companies) is the basis for the business model of the 21th century.
2. Because it's the difference between good and great, between on and above customer expectations, between surviving with life long frustrations and outgrowing old pains and thereby outperforming competition.

Examples aplenty, on organisational and also on the projectlevel. I have mentioned a good example in one of my previous blogs (the case of ING direct in the US). Read the book "from good to great". I am sure there is some outstanding book out there about Network economies.

Looking at the relation between Sales and Delivery in any commercial organisation intuitively that tells me that formalising feedback and lessons learned is no easy step.

Looking at the relationships between e.g. the business analyst and the developers in many a project team it tells me that feedback and lessons learned is no easy step

Looking at the preconceptions many marketeers (or any business department on that matter) have on techies or IT people and vice versa means that cooperation is not going to happen spontaneously.

Source image: http://www.theinterpretersfriend.com/misc/humr/serious.html

Integrated Business & IT Project Management.

In most cases IT is not the end goal but a means to support the business strategy and business goals. Projects should be managed explicitly from this insight and therefore could better realize the potential of IT for the Business. The approach of good Business & IT Project Management" is therefore based on the following goals:

• exhaustive and clear setup of the project governance on the Business side
  
• flexible and transparent setup of the IT projects
• continuous but efficient feedback between the Business & IT.

Additionally it is advised to identify and realize 20% of the effort that realizes 80% of the benefits. This approach contributes to the control and predictability of the projects without diminishing quality and added value.

Integrated Business & IT Project Management.

Increased competition drives management simultaneously to more innovation and cost reduction in operations. Offering innovative, added value services to their customers becomes a must. Such services are mostly realized by better integration of business processes. IT must keep up the pace with this development (or ideally be ahead of it).

Example: more and more back office business logic and company data is being pulled into the front office systems to allow 'cleaner' sales order entry and better customer service in the Points of Sale. The data or information in all corporate databases must become ubiquitous, in other words if the Business wants to serve the customer better it must 'self-evidently' be able to get hold of all information anywhere, anytime and anyplace.

SOX compliance regulation is another force that puts complementary demands to the integration of Business processes and IT systems.

Result: there are more links between the IT systems, the business processes and IT systems are more tightly coupled, business processes are becoming more integrated in the Supply Chain, the governance and stakeholder structure is becoming more complex.

Phenomenon. Almost every (innovation) project initiated by the Business becomes a chain-project with involvement of Business and IT stakeholders across the entire Supply Chain. From experience I learned that these chain-projects are considerable more challenging to manage and control.

Conclusion. The higher occurrence of chain-projects and growing dependency between Business and IT can be viewed as two challenges that face Project Management. The profession Project Management must adjust and evolve to transform these challenges into success. I practice project management that puts cooperation between Business and IT central and where the multitude of stakeholders gets managed effectively.

Image: name of the photogenic dog is Pepper, picture taken in Varsenare Belgium.

Questions seeking answer

Should IT Service Providers and IT departments:

• inject the enterprise (or software) architect in the sales process
• first invest in business and IT alignment (pre-sales) before selling solutions (sales)
• formalize the feedback loop of lessons learned between delivery and sales
• be building business skills in IT staff or push IT skills in business staff?

Replacing legacy applications: rebuilding is never just 1 on 1

Click the image for a closer look.

The proverbial cheese in the mouse trap for a client that wants to replace old systems with new technology is that replacing legacy is a straight forward and risk free assignment that requires little involvement of the Business.

The figure above shows 7 topics that require intense cooperation between the Business and the IT team.

Service Oriented Architecture (SOA) is dressing for success

Expect the unexpected

Change is the only constant and that can be a good thing for the end result of a software project. Increasing insight by all team members into what works and doesn't is vital. The agile movement maximizes the added value of new insights.

Projects are however continuously under attack from unexpected negative things happening. Murphy's law...

A 'striking' example of a sudden negative impact is the following scene from the war in Iraq.

Sounds like ... IT project

IT project disasters are still among us as much us ever. I am always left somewhat pondering when people ask me why IT keeps getting it wrong, it can't be that hard can it?

IT remains a 'magical' black box for many people. The illusionist (i.e. IT project team) does his or her thing and no one of the spectators (i.e. Business) understands what is happening behind the curtain.

The essence of IT (projects) is not the technology or the jargon used by techies BUT … (1) people and (2) that fact that projects are unique and one time only by definition.

Bear with me, I am asking some imagination of you as a reader… there can be found many good metaphors for the complexity of IT projects using non IT related examples. Don't get me wrong, I am not making any excuses for project failures. I merely want to show that the challenges for IT project teams are not small or benign. The following metaphors should give an idea where something can be done to control the complexity and risks.

I have transferred 2 non IT related people activities to the world of IT projects:

The non-IT world	Metaphor in the IT world
A symphonic orchestra	In the IT world the orchestra is asked to: play a new concerto for the first time play with team members that they don't know and have never played with before practice but all instrument groups are practicing separately all instrument groups only come together once, but only to talk about the concerto and not actually play together work with 3 different conductors that have no contact with each other to play with all instrument groups together for the first time only on the night of the performance
A family on a car trip to their holiday destination	In the IT world the family is asked to: go to a France for the first time to an unknown address in the Provence drive with no GPS, they get just a map that indicates only the national highways (the rest is uncharted territory) arrive at an agreed time (set ambitiously) In the IT world: only one person of the family can speak just a bit of French to ask directions only one other person can drive but cannot speak French passing through Paris is the only way to get there in time thankfully its no holiday season but helas no one knew that there were lots of roadworks on the major highways that they had to pass because the journey is somewhat uncharted territory is difficult to estimate the money needed for petrol/gas and for food and drinks on the way.

So what would YOU do so that:

• the orchestra would receive a standing ovation on the night of their performance?
• the family will reach their destination (in time)?

Grouping critical success factors for software projects

This is a model that has helped me to explain to people that project management alone is not enough to ensure success in software projects. It's a very simple but powerfull image that you can use in making all stakeholders aware what the main groups of critical success factors are. Per group you can identify the 'as is' situation, current lessons learned and define any usefull short or long term improvement initiatives.

Business & IT alignment (c.q. the innovation potential of IT for the business) cuts vertically accross these four groups.

On each level (or box in the figure) Business and IT should find a way to work together and become successful in business innovation.

What is web 2.0

Intuitively I feel that Web2.0 is about an increasing group of consumers that will have a major impact on the business models of any company that wants to survive in the immediate and long term future.

The bold slogan of Tom Peters "Innovate or die" has a great relevance here.

I have done some online research and gathered some web2.0 descriptions that make sense to me:

For the first definition (from Andy Gutmans) see image above + this Youtube film below.

A second good description I found on the following website: http://www.connectedcustomers.net/category/web-20/

"Think of web 2.0 as a mindset that will lead to a more fluid interaction between websites and connected customers. Web 2.0 is more a way of thinking than a technological advance. Building things from the bottom up as opposed to the top down to give the customers what they want and need is what web 2.0 is about.

When web 2.0 is positioned as a mindset to enhance customer interaction and satisfaction I’m all for it. Unfortunately the only thing I could find that was new about web 2.0 is having businesses and marketers that now think about the customers needs first. "


Tim O'Reilly states in a film i found on Youtube :

• • the network is the platform
• •the rules for business are different
• •cardinal rule: “users add value”
  
• •figuring out how to build databases that get better the more people use them

A fourth description I composed from different sources (including yours truly):

Web 1.0

• users reading content

Web 2.0

• is an evolution (no revolution) of the content creation, and publication aspects of the web. [http://intentionalweb.org/]
• users producing content, sharing and interacting through content
  

web 3.0

• users sharing functionality through micro applications (Eric Schmidt CEO of Google)
  
• the Intentional Web. A focus on improving the content consumption end of the web now that we have very dynamic and malleable content. [otave.com]

Everything there is to know about Business & IT

I set myself the audacious goal of creating a single slide that would show everything there is to know about IT and its relationship to the Business. Here is my first attempt, let's have it! (your comments that is). Just click on the slide to enlarge the image.

BHAGS, pronounced “bee-hags”, are Big Hairy Audacious Goals. This term is applicable to the slide as well as to the area of strategic marketing and business road mapping (see also the image of my previous post).

What is Business Project Management

Despite having mentioned it in my blog description I prefer the term Business project manager over IT project manager. The latter term distinctively leaves out the Business and it gives the impression that the project is managed & directed by someone from IT. Nothing is further from the truth, it is the responsibility of the business to manage and direct the project from within the business ('even if it is an IT project').

The most striking lessons learned I have come accross in outsourcing (offschoring as well as contracting) is that the clients neglect to balance & safeguard IT knowledge on their side. This is especially problematic for the client in fixed price contracts. Not (adequatly) implementing IT governance on the business side is prohibiting adequate control, insight and quality assurance on the business value of the IT project.

Anyone familiar with PRINCE2 will know that the project manager is a role on the client side i.e. somebody in direct contact with the sponsor (or Executive) of the project. An IT project manager in PRINCE2 is a team leader controlling the execution of the project. If you work for IBM and you are coordinating a multi million dollar project for a client and you report to a project manager on client side you are still a team leader.

Since 99% of the IT projects really are business projects that have an IT component I advocate the term Business & IT project management.

P.S. The tiger monastery near Kanchanaburi in Thailand has a truly Big Hairy Audacious Goal and business model, check out there website.

Adopting new IT technologies by the Business & IT

I attended an excellent seminar in Brussels on "The future of ICT" on October 4th organised by IT works.

I noticed a few things:

• In the folder and emailings it stated that the targeted audience was ICT decision makers involved in IT planning and management.
• I checked the attendee list and 95% of the people present were working in IT departments, the other 5% were heads of business deparments who where directly involved in IT projects
  
• When talking to people during the breaks people where frustrated that the business leaders did not understand why new IT technologies were important

I borrowed a few lines (below) from "http://www.computable.nl/nieuws.jsp?id=2157297"

Gartner states that CIO's and it-managers should implement disruptive technologies to stay ahead of the competition.

Examples of these technologies as mentioned in the article are:
1. Multicore
2. Web Platforms
3. User interface
4. Web mashups
5. Sociale software
6. Tera - architecture
…

I believe that CEO's (and business people in general) are the final decision makers on which technology to use to gain competitive advantage in the market and these people are not going to go all warm inside from technical concepts like mashups, platforms, Web2.0. That's for sure and is absolute normal because it's not clear what these technologies can do. More importantly even if you convinced the business to invest in e.g. SOA this technology might not be supported by a change in vision/culture/thinking in the business making it difficult to reach its full potential.

Your CEO is not going to become enthusiastic when hearing your speech "We have to change coz we have SOA, and web2.0 now".

Whereas if you explain to the business that the customer base is increasingly composed of 'IT natives' (people who were e.g. using the web, mobiles, and messenger from the cradle) who expect any company to respond via and communicate via web2.0 phenomena (like: all communication is digital, peer2peer networks, all the time real time contact via messenger & mobile phones, blogs & wikis)…

If you explain to the business that any authentic and feasible implementation of such new relationship with the customer requires that these new expectations of the consumers are to be reversed engineered into all layers of the company....

If you explain to the business that the making your company (web)service oriented is a good way to go about this back office implementation…

Then I believe the business and IT have a better basis for understanding and decision making.

Interesting example is the paperless world of ING direct.

Marketing and back office implementation

I am a 31 year old project manager, forged, born and bred in the IT sector for about 7 years now. This is the first entry in my blog, I had this blog for a few months now but a recent event has triggered me to actually start using it. Btw, for everyone who wants to find more about my background check out my website on www.tomvandewiele.com. The event in question is the following: on the 24th of September i started a four day class of marketing in the TIAS NIMBAS Business School in Tilburg (the Netherlands). Amongst the 20+ participants i was the only IT person. It was costly and i had to pay for it myself but it was worth it!

ING Direct, Zara, H&M. Does anyone have any idea what these companies have incommon? Besides being amongst the most profitable companies in their respective sector, they all have build their business model and competive advantages on an intricate combination of Marketing and IT.

If you would do a random survey amongst employees in all sectors and you would ask them which departments are the most opposite in their company... my best guess would be that they mention Marketing and IT as a typical example of two worlds far apart.

One could argue that the survival of any business in the 21th century is dependent on the these two worlds cooperating and getting to know each other better.

Food for thought in this article and the excerpt below:
+ "4% of organizations have website overloads and crashes as a direct result of a lack of communication between the marketing and I.T. departments.

The survey also showed that in 28% of the companies, the marketing department does not alert the I.T. department about impending website marketing campaigns at all, and 46% of them only talk to the I.T. department immediately before the launch of the new campaign. In addition, only 75% of the marketing professionals surveyed knew how much traffic their websites could handle." {excerpt from http://www.geek.com/marketing-and-it-dont-talk/}

Let's replace in the above exerpt 'campaign' by 'product' and 'website' by 'production capacity'. I am currently working at a major Dutch Telecom player as program manager in the Retail department, at my workplace on a board i have pinned an artical which stated that the dutch consumer organisation gives up the fight with the telecom giant in relation to the thousands of people waiting for their new internet connection and VOIP products to be delivered.

The marketeers had created a very good product but somehow the company failed to ensure proper implementation in the front and back office. The IT systems were not properly adjusted to the new products, the engineers that deliver and service the products could not keep up with the demand. More than 50% of the orders for this specific product was not going to be delivered in time (or never in the case the client cancelled his order). In their peak, they received ca. 20000 extra orders for this product combo every week.

My conclusion and opionion is that Marketing needs to be given a more formal mandate (together with IT and the production department) to realise an adequate implementation of new products and services. This closeness between departments is also crucial for the operational activitities, continuous improvement accross these departments has a huge potential for reducing life long frustrations and conflicts between departments and also for improving customer service.

I hope to receive your thoughts on this.