CIOs – Don’t fall for Greed Computing

For decades, IT has made Enterprises more performing by processing Information, automating processes, opening new opportunities channels, capturing real-time data, improving the collabaration of business partners, developping online value added services. This commitment of performance was driven by the necessity to be competitive, and beat other players in the same field of business. Being performant is contextual by nature as it is defined by the current market expectations. By and large, performance could be approached in term of market reach,  Product innovation, productivity or customer wealth.

The deregulation of financial markets have made Enterprises more focused on the immediate wealth of their shareholders, leading to define performance thru the financial value of their stock. If yesterday we could assist to executive meeting addressing new comers in the market, pricing strategy, product innovation, it is today more or less a matter of cash. The focus is not business anymore but money. As this statement could sounds like an old say, and something like “nothing new here”, it makes all the difference.

I’m a firm believer of passion at work, only passionate people accomplish incredible things. To lead a successfull business, you have to believe in it, fight for it, leave by it and eventually get money out of it. If money is the ultimate objective of business, what drive people to create and grow a business is the opportunity to leave an exceptional experience, what drive them is passion. If this is not the case, don’t waste your time as a business leader, go to the stock market, your passion might be money. This change in focus, from Business to money has created a new profile of the executive team leading to conceive businesses as a portfolio of share and considering the human factor as the major risk.

IT leaders have during years serve Enterprises for better business performance, this is what make them wake up every morning and fight for them. Today they are facing an important challenge: reducing the workforce thru IT, and eventually being considered as an important cost to curtail. Does it sound like passion anymore?

Related post: Creation of value is a true responsibility

Project documentation – value for money?

I’m always baffled by the volume of documentation generated by a project. Pages of text and flow charts describing business & system requirements and project documentation.  Now, think of the value of this documentation during and after the project.

One wise man might ask: “why so much energy is consumed by the project team and what value am I really getting out of this.”

Let’s have a look on the type of documentation and the way there are managed. I will focus on the three majors although they are many others that could worth the effort to explore.

• Business Requirements Documentation
• System Requirements Documentation
• Project Management Documentation

Business Requirements are usually written by consultants or integrators to ensure  a correct understanding of what the customer meant, and further configure or code the appropriate piece of software. These documents are most of the time written with word processor and are going thru several cycles of validation. It is not unusual to see thousand of pages produced with reference to each others. This heavy package has an additional objective: it is to protect parties for what is in scope and out of scope of the project  The advantage is very often more on the integrator side as “what is not written, is not in scope” and what will drive the workload on resource is only know by them as they are the experts of the technology or system they are implementing. To balance this shift in power the customer is insisting on seeing every thing he can think about in these documentations. Moving forward the quantity of documentation will measure its quality.

System Requirements is a different animal but surprisingly managed the same way. Based on the Business Requirements the Integrator is producing the technical translation and asked a customer validation on something he/she can not understand. Based on the complexity of the software or technology it becomes sometime absurd.

Project Management is usually more used in a strategic manner, as it is one of the first documentation that is produced. Heavy and nice package are produced that nobody is looking at when the project kicks off. In addition this documentation is distributed to the project team without much explanations.

My piece of advise will be to set up clearly the rules upfront with the selected partner and make it part of the contract itself. Project documentation consumes more or less half of the consulting effort, be pragmatic and focus on your needs.