TRIZ is an engineering concept created a long time ago in Russia.  It proposes that there are 39 main features to any system, and that these can sometimes be conflicting, like for example speed and reliability in a Formula 1 car.   The TRIZ matrix puts these features on the axes of a matrix, and list principles that can me applied to mitigate these apparent conflicts.

I have translated these Principles and Features into a Software systems analog to attempt to use the TRIZ matrix as a Software architecture tool.

The 40 Principles are listed here: triz-but-those-russians-are-clever/

The Features of a System are:

1. Weight of moving object – Average Size of Message
2. Weight of stationary object – Total size of Data Repository
3. Length of moving object – Number of Fields per Message
4. Length of stationary object – Number of Databases comprising System Data Repository
5. Area of moving object – Size of Metadata contained in a Message
6. Area of stationary object – Number of Tables Comprising Total system data repository
7. Volume of  moving object – Size of Message/Data Payload
8. Volume of stationary object – Size of Code
9. Speed – Speed
10. Force (Intensity) – Guaranteed / Not.
11. Stress or pressure – System Load
12. Shape – Memory Constraints
13. Stability of  the object’s composition – Stability of Code Base
14. Strength – Robustness
15. Duration of action of moving object – Per Message/Transaction Processing Time
16. Duration of action by stationary object – Overhead Processing Time
17. Temperature – Speed of User Interaction
18. Illumination intensity – Usability
19. Use of energy by moving object – IO Intensiveness
20. Use of energy by stationary object – Processor Intensiveness
21. Power – Ability to do work
22. Loss of Energy – Reduced Processing Capability
23. Loss of substance – Lack of Message Integrity / Messages Lost
24. Loss of Information – Loss of information
25. Loss of Time – Loss of Time
26. Quantity of substance/the matter – Size of Database
27. Reliability – Reliability
28. Measurement accuracy – Data Accuracy
29. Manufacturing precision – Data Precision
30. Object-affected harmful factors – Side effects on Code
31. Object-generated harmful factors – Side Effects on Data
32. Ease of manufacture – Ease of Coding
33. Ease of operation – Ease of support
34. Ease of repair – Ease of Troubleshooting
35. Adaptability or versatility – Flexibility
36. Device complexity – System Complexity
37. Difficulty of detecting and measuring – Difficulty of Instrumenting or Monitoring
38. Extent of automation – Extent of automation
39. Productivity – Productivity

I have noted with interest that many people inside organisations operate without regard for the good of the organisation, or with a grossly faulty view of what is good for the organisation. Some people operate with their own departments interests in mind instead of the overall organisation’s interests. This is probably a fairly obvious statement, that anyone who has been in business for more than a few months will know to be true.  The issue of concern is how many senior executives seem to be willing to allow this behaviour to persist, once they have become aware of its existence.

• I have seen Executive committee members that win favour with the CEO by painting their colleagues in a bad light, thus making themselves look “relatively” better than the next executive.  Once this becomes a culture the organisation is on a downward spiral;  The “least-bad” executive gets a bigger share of the ever-decreasing bonus pool.  It is almost as dysfunctional as trying to grow a business by cutting costs – it is doomed to failure.
• I have seen some IT organisations that have no immune system, and exist in a state of being continuously on life-support.  Actions have no consequences, because the life-support will ensure we go on living, and short-termism can make a new executive look good long-enough to earn a nice bonus, and then leave the organisation in a worse state, but still alive.
• I have seen some organisations where sales teams from 2 divisions compete against each other to offer their solution to the same client, sometimes cutting the price down as far as “cost” to ensure winning the next sale.  When said this way, it is the most obviously dysfunctional behaviour, yet the incentive-schemes of the sales managers insists that this is the best course of action for him or her.

It is fairly easy to imply that these individuals, acting out of self-interest are at fault.  Surely they should know better, and should be acting in the best interests of the organisation. This is just common sense.

On reflection though, dysfunction in organisations is usually a dysfunction in leadership; Partly because leadership allows the issue to persist and grow, but also because the leadership does not put in place a carefully thought out mechanism to ensure that everyone concerns themselves with the correct and proper outcomes.  Performance management is simply a necessary evil imposed by HR on management.  We have to tick the boxes, but really don’t run the business using these mechanisms.  Hard to believe, but this happens!

For example the competing sales-team issue is simply that incentives and structures in the organisation drive that behaviour.

The short-termism issue could exist because Executives cannot be made to take accountability for their actions, because Board members and shareholders do not know enough about the inner workings of the business to challenge the existing approaches and define a proper set of objective measures for the new appointees.

The finger-pointing and blame-shifting game exists simply because objective measures of a manager’s success are not defined or measured.

Open and honest, robust internal debate is very valuable and healthy, but when the agenda is genuinely not for the betterment of the greater organisation, this becomes a very serious cancer.  An honest individual can be misguided about the correct path, have incorrect or incomplete information, they can have flawed logic, or lack a broad enough education on the topic; All of these can be overcome by debate with colleagues which can result in the betterment of the organisation.  The requirement here is simply honesty, and a genuine desire to act in the best interests of the organisation. If those are missing the organisation has a virus in it that if the immune system does not expel it, will eventually kill the organisation.

I would suggest that the real cancer is weak leadership:

• Unable or Unwilling to deal with the bad apples who are creating dysfunction.
• Unable to set a clear objectively measurable course for the business.
• Unable to see beyond the current ways of doing things, or challenge existing business models.

The IT Leadership Problem

The Leadership problem in IT is compounded in organisations such as the one described above, because IT is seldom understood at Board and Executive level.  When the CIO gives his report the attendees catch up on emails.

If the trust between CEO and CIO fails, it is often because they misunderstand each other, not because of genuine mischievous intent on either part.

Sometimes it is because the CIO was promoted through the ranks of IT, without genuinely being the right person for the job.  I have seen some sincere Corporate IT leaders who genuinely think their job is about the coolest latest technology; But management is about people, and good IT-people are not often great people-people. Obviously a good CIO should have good technical knowledge and be a great people-person.

Occasionally I have seen great candidates for CIO within an organisation who suffer under a technocratic leader because they are too junior to be awarded the role.  Once trust between the CEO and CIO is lost, the CEO is unlikely to look to them within the IT organisation as a successor to the outgoing CIO.  So the CEO appoints someone he or she trusts;  Usually someone with little or no IT experience.  These good Junior candidates should take the opportunity to ally themselves with the new CIO, and help him, and also learn to be great leaders in a relatively risk-free way.

****************

If you are that promising junior IT resource, or this newly appointed CIO without IT experience, then read this blog.

If you are a long time CIO, and you’re constantly at odds with the Board or the CEO, I doubt you’ll enjoy this blog, but if you can manage to read it, I’m sure it will help – like awful-tasting medicine.

If you are on that Board, or you are that CEO who doesn’t see eye-to-eye with your CIO, then this should be an interesting read for you.

*********

Before wrapping up this rather cynical and bitter post, I’d like to say why I think these things happen:

• Well thought-out, Measurable Organisation Objectives are not set, or there are too many to manage effectively, or they are not used for daily management.
• Well thought-out, Measurable IT Objectives are not set, or they are conflicting, or they are not used for daily management.
• CIO’s are promoted through the ranks without regard for their aptitude, and end up managing technology instead of people.
• Poor Leaders let the resultant problems escalate instead of stopping the rot early.

*********

Enough of setting the scene… Next time we’ll consider some research in the field of IT Performance.

So few shining lights…

One of the significantly talked about things in Corporates is how [Insert IT buzzword here] did not deliver on its promise, and quite possibly it is one of these in your organisation:

• SOA
• Big Data
• E-Commerce
• BI
• Intranets
• Collaboration
• IP Telephony
• Business Process Automation
• Document Management
• Mobile Work
• Help Desk (some staff asserting that the word “help” should be removed from the name)
• The IT project Office (ensuring that IT Projects deliver on time and on budget)

…and so on.

Are these things unworkable? Will they always be a problem? Are the technologies immature? Are IT People just unruly and unmanageable? Will IT Projects always overrun and under-deliver?

…so be better

We all know of organisations where one or more of them worked well. We have been to seminars where people talk about great successes. We see some organisation leverage a particular IT advantage to huge profit. We feel aggrieved that our own organisation seems to be incapable of similar success…but why do these successes seem to be so few and far between?

I have been in IT Management for over 15 years and involved in corporate IT for around to 22 years. In my experience the overwhelming majority of conversations about IT that corporate staff engage in, are negative ones. In truth the overwhelming majority of ALL experiences that people talk about seem to be negative ones – just look at the news and media.  So researching the anecdotal material available will simply confirm the sense we have that all is not well. My purpose begins to emerge:

• To bring IT into good repute in corporates
  • by helping them to be of good repute.
  • and helping them to be seen to be of good repute
• To have IT staff seen as the hardworking, capable, intelligent and focussed people that they usually are (exceptions excepted :-P)
  • To weed out those exceptions
• To have corporate IT departments seen as essential Partners in the success of a business.
  • To give the IT Management team the tools to bring that about.

As usual the answer lies in understanding leadership and strategy in an organisation. In this case, specifically how leadership influences and interacts with the IT Department and Technology in an organisation (And I include IT Leadership in the category of Leadership) and how Organisational and IT Strategies interact..

• Are you curious as to why these things seldom seem to work out, or what can be done about that?
• Could you possibly influence some of those outcomes in your organisation?
• Do you perceive the Performance of your Company’s IT Department to be suboptimal?
• Are you an IT Manager or CIO?

Then this blog is for you.

…or Die

There are a number of things that are inevitable in the long term (certain to happen, unavoidable, unpreventable even) that few would dispute. I will call them generally accepted inevitabilities:

• Businesses will depend more and more on Technology to function
  • therefore Technology and Business Strategy will become indistinguishable
  • therefore The IT Management Function and the Business Management Functions will be come indistinguishable
• The number of IT Functions that are considered Commodity IT functions will grow, and those considered Core Strategic Business elements of IT will diminish.
  • therefore outsourcing of commodity functions will expand
  • therefore management of Core Strategic IT functions will become more critical
• The IT Department will change to align with the above inevitabilities.
• Organisations (and people) that can embrace these inevitabilities early (but not too early) will have an advantage.
• Embracing these changes early, will cause them to happen faster, thus disadvantaging those who are not ready.

There are many ways to embrace these changes, but I believe the ideas in this blog, properly applied, will prepare organisations and people for these changes.  So unless you are just waiting to die, this blog is for YOU.

The first pain was trying to purchase a copy.  Go to Incredible Connection… Ask for Windows 7: No longer available.    Okay lets try windows 8 then and hope it works… sigh.  Only available as an upgrade, you have to have a previous version of windows in order to install it.  WHAT??!!!

That is the most arrogant thing I have heard of since Ferrari made models that only previous owners were invited to buy…and I feel that Ferrari are sort of entitled to a little arrogance.   Maybe this is more akin to when Renault did the same thing with their V6 Cleo.

…but wait Windows 8.1 is available, not physically in South Africa yet, but virtually for download, and THAT is a full product not requiring you to have a previous version of Windows!  yay!

OK so I trot off home and purchase the 2 copies I need.  The download link downloads a downloader, which requires Windows to run!!!!!!!!!!!!   Wait, I thought this version does not require you to have a previous version of Windows?  Sigh.  I give up.  I fire up a version of Windows 7 I have installed on my laptop that I bought with parallels 7.  Download their blessed downloader and execute.  It gives three options: Install now, Create media, and Install later (which as far as I can tell just exits the app :-).  OK perfect, create media is what I want.  Next page asks if I want to install to USB flash drive or ISO file.  cool.  this isn’t so bad.  I select ISO and it starts downloading. Downloads in 1 hour… no problem.

Attempt to install.  40 minutes later finish install.  But wait, it has installed the 32-bit version on this 64-bit computer.  Hmmm….the ISO I downloaded seems to only include the 32-bit version???  I need the 64-bit version.   Log back onto the Microsoft store, search for an alternate link.  nope.

Call Microsoft support.  First few times I made the mistake of mentioning that I was installing to an Apple and immediately they tried to transfer me to someone who could help with Bootcamp.  Argh!!  The problem is not Bootcamp, the problem is downloading a 64-bit version.  Eventually after several calls I got to the point:  “OH. no you need to download it from a version of Windows running the same architecture as the version you want to download. ”  WHAT!!!????   Not only do you need to have a copy of windows to execute the downloader for this “Full Version”, but you also need to have a previous version running the same architecture that you want to download.  It makes this decision for you with no consultation or notification whatsoever.

Nowhere on any of the screens I encountered (and I have now done this many many times looking for it) is there any warning or information  to this effect.  The only way to find out which version you are getting is to try to install it, and when you are finished with the whole install process you can check and see if it is the version you wanted. Neither the download page on the Microsoft Store, nor the screens in the Downloader Application, nor anywhere during the installation process are you given any option or warning about which version you are getting.

After 3 hours on the phone of trying to find an alternative, the only option available to the Microsoft staff was “We’ll give you a refund for the download version, and you must order the DVD media….5-7 working days delivery.”  No way to download the 64-bit version of this full product unless you have a 64-bit version of a previous version installed and running somewhere.

WAKE UP MICROSOFT!!!!!   This is the worst software purchase experience I have ever had.  ever.

• Analysis of the Organisational Strategy clearly showing how the Technology strategy Aligns, and if it doesn’t – giving recommendations on how to make it align.
• An Analysis of the Business Functions and key processes, clearly indicating which systems support those business functions.
• A Health Assessment of those systems indicating their systemic health, degree of alignment with the stated business strategies and functions, satisfaction of the users, and technology lifecycle perspectives.
• A Technology Roadmap integrating Business-Unit-level roadmaps and initiatives into a single Enterprise level Technology roadmap.

BUT…

It could take years to establish a functioning Architecture Practice that produces and updates such a pack on a regular basis (depending on the size of the organisation).

So my approach would be to create a high-level draft Architecture in a few months, that will then become the basis of incremental improvement as the process gets established.

If one tries to map all Business Functions and processes to a task level, before mapping systems, before creating a roadmap, you may take too long to get to the point of having any useful impact.

Every Architecture artefact MUST help the organisation to make better decisions, faster.  There must be (and there is) a way to prioritise the EA deliverables in such a way that they impact the “next” important decision just in time.    I am a great believer in creating a mile-wide/inch-deep Architecture view first, from which priorities can be selected and more detailed work can be done.  Very often mile-deep efforts are never finished, or they result in EA investment being cut, because they take too long to yield useful results.

Establishing an Architecture Practice

So my approach to EA establishment would be:

• Assess the enterprise from a high level-strategic perspective
• Decide on the set of EA artefacts needed initially
• Plan the phases of the EA establishment programme
• Create very high-level drafts of the EA artefacts very quickly
• Incrementally populate those with information, but start using them as soon as they contain useful content.
• Expand their use as their content evolves to become more useful

This way value is gleaned early from the Architecture efforts, without compromising the ultimate objective of having a complete set of EA artefacts to guide all the relevant IT decisions at the end of the establishment programme.

In the process of establishing an architecture practice it is also critical to focus on establishing the processes and inserting them into the decision making process as soon as possible.  The earlier that  existing  IT decision-making  processes become used to requesting Architecture input and guidance, the better.  In many organisations with mature management, where architecture is in its infancy, the managers all want a piece of the new architect as soon as they walk in the door.  Mature Managers recognise that there is huge value in making better IT decisions, and the way they can do that is by having proper architectural guidance.  The trick is deciding who to help first, and how to prioritise that effort.

With the Priority of Architecture Artefacts established, the problem of which Business Area’s to start with comes into focus.

The Health / Importance metric.

The Importance metric applies to both Business Processes and Systems supporting them.  Some Business Processes are critical to an organisation, and others cause only a small inconvenience when missing (e.g. pause-area coffee replenishment process – except for Software development companies which run on coffee).  Others are critical at certain times of the month and almost irrelevant at other times (e.g. payroll).  Similarly systems supporting a business process may have varying degrees of criticality.  Either way, one of the important metrics to help you prioritise you efforts is going to be some measure of the importance of each Business process and their supporting systems.

The Health Metric applies to systems, and it measures the degree to which that system is functioning reliably, and meeting the business requirements of its respective business process.  Some technology aspects can also be brought into the health metric, such as obsolescence, and ability of the IT Organisation to monitor and support the technology being used.

I have a standard set of survey questions that I use to determine the Health and Importance metrics, that I adjust slightly depending on the organisation’s requirements.

This information is then plotted on a simple 2×2 matrix indicating the Importance versus Health.  Obviously the items that are important and Unhealthy are your first priorities.  The Unimportant Healthy Systems are obviously your last targets, leaving  Unimportant-Unhealthy and Important-Healthy as your second Targets with some discretion applied.

For Most Organisations, a matrix like this can be completed in a few months and usefully inform the Architecture Priorities; All the while you are getting on with the basic establishment of Architecture Processes, Governance Bodies etc.

So now armed with an approach to prioritising EA Artefacts, and an approach to prioritising the Business-Areas. the EA programme looks less overwhelming, and questions about when it will start to pay off, can easily be answered.

Agile approaches to Software development and Remote Developers are often avoided as mechanisms because of several misconceptions about Agile that organisations view as risks:

• Agile teams don’t plan.
• There is no design in the Agile approach
• Agile teams do not test.
• Agile = no documentation.
• Loss of management control

(Note that all of these are untrue)

The statistics on Adoption of Agile are compelling, with 83% of the organisations surveyed (Versions One’s 7th Annual State of Agile Dev Survey) saying they would definitely do Agile Projects again, and 70% saying that Agile allowed them to Deliver projects faster.

So why the resistance?  I’ll answer that subjectively first by saying I was a skeptic until I saw one Agile project work well:  Now I am a convert.

What about the remote workers?  The survey showed that Agile was also useful in managing distributed teams very effectively.   The fact is that your developers sitting in the office could just as easily skive-off while they are at their desk.  They get interrupted by noisy colleagues, adhoc meetings and the daily commute.

The origins of Agile are in OpenSource distributed teams, creating a process to allow them to work effectively together and deliver productively.  This takes discipline! The Cynic in me says that corporate software development teams do not want that amount of discipline – it’s hard work.  And it seems to have been easy for them to convince management that this Agile thing is no good.

“To say that companies or CIOs are reluctant to embrace agile is like saying they wouldn’t take aspirin for a headache….And they’re not only not taking the aspirin, they’re banging their heads against the wall and wondering why it hurts.” – Jim Johnson, Standish Group Chairman

On the distributed team issue, surely it makes sense that the very best people for a given project may not all be located in one place, or near your offices. Why limit yourself to the resources near you?  Why not get the benefit of the best the world has to offer in a given technology? We now have the mechanisms to help them work effectively together with the internal teams, but we need to follow the disciplines to get that benefit.

I would challenge any manager of an IT team that includes software development to read these survey results and remain skeptical.  

Hopefully I’ll find the time to comment soon.

Many people thought it was lame, but I believe they understood the principles after reading this… and here it is:

IT LAND

Early one morning a man by the name of Walter Widget arrived in IT land. He had heard of the fabled efficiency of IT land as a place to do business, but so far it looked pretty ordinary.

That afternoon he decided to take a walk into the industrial district and pick a site for his new factory. As he walked down the street, he noticed that the street ended abruptly just as it reached the last factory. “that’s odd,” he thought, “They haven’t catered for growth at all” Suddenly some objects on the ground caught his eye. They were lying in the grass just beyond the end of the road. There were three old oil lamps, bronze, silver and gold. Being a wealthy businessman he decided to inspect the gold lamp. Inscribed on the side it said “IT land self-service infrastructure. Genie within. Rub lamp for Gold service”

Intrigued Walter rubbed the lamp, and lo and behold a genie came steaming out of the lamp to tower over the surprised businessman. “Hello, my name is Bert, and I’ll be you infrastructure Genie today, Your wish is my command! ” bellowed the genie. “How about a nice cup of tea?” said Walter, now in a bit of a state of shock. “Sorry said the Genie, I only do the infrastructure bits, you’ll have to consult the refreshment genie; He has a little cart and should be here around 3:30”

“Ok then” said Walter “How about a Widget Factory?”

“Not really sure what they’re like said the Genie, can you describe one”

“I have the plans right here” said Walter, beaming as he presented a complete set of Widget factory plans to Bert.

“Ah right!” said Bert. Suddenly there was a pop and Walter turned white, now in a full state of shock. Walter sat down on the bench that had appeared beside him in the suddenly-landscaped garden.

A complete factory had appeared, with the bit of street that extended up to the factory entrance, street lamps, parking bays and a huge lit sign in front that said “Walter’s wonderful widgets”

“Wait a minute!” said the Genie as he handed Walter the Itemized first-month’s bill, “Are you Walter of Walter’s Wonderful Widgets?”

“No” said Walter inspecting the bill, “That’s my father. I travel all over the world setting up the factories, but I’ve never seen anything like this! It normally takes months!”

Walter managed to stand and wobbled through the front door of the factory building. There was a huge teak reception desk, a thundering water feature, and soft music playing in the background. “Wow!” said Walter.

“Well you did request the Gold service” said Bert noting the expression on Walter’s face.,

As they went beyond the reception area, Walter saw that there was no machinery in the factory, but neatly arranged power outlets, benches and fittings where each machine should be, and an overhead fire-sprinkler system.

“What about the equipment?” he asked. “Ah” said Bert, “Sorry, I only do the Infrastructure bits, but the Solution Genie’s already have your plans and are hard at work putting together the equipment for your new factory. I’m sure they’ll be along shortly, oh and by the way, since you picked the Gold service, there is now an identical factory standing-by on the other side of town, should something happen to this one”

“Wow again! Was IT land always like this?” asked Walter, amazed.

“No”, said Bert. “About 5 years ago the king and his advisors declared that they were going to change the way things worked here. They sent notices of their intentions to all the Resorcering bureaus and the top wizards from all over started pouring in with the challenge of building a state-of the-art magical infrastructure. (Many of them lived right here in IT-land, but had stopped practicing real magic”) And the rest, as they say, is history. There are some challenges and as you saw some things just can’t be done with magic yet, but they’re working on it. Also we couldn’t do any of this if people owned their own land, because we have to maintain the underground magical conduiting to make this possible. That’s why your bill is for monthly service. If you decide to close your business, all this will simply disappear.

“Now I really need some tea” said Walter and set off back to his hotel. “What an amazing place” thought Walter as he walked. “I think I could enjoy living here” and he resolved right then to make IT Land the new headquarters for Walter’s wonderful widgets.

One of the difficulties with implementing a software factory is measuring development-team performance. Depending on the culture of the team, and the desired outcomes for your team, the approach may be fundamentally different, but here is an approach I have implemented, that I believe is fairly unique in a corporate environment.

My Objectives were:

• To change the culture from one that was inward-looking (every problem is solved by writing some code) to one that considered external commercial or Open Source solutions (a problem can be solved in many different ways).
• To reward outcomes rather than inputs, i.e. the primary concern is that the project objectives, the deadlines and the architectural principles and standards were all met.
• To allow developers some freedom to choose their projects
• To encourage information sharing, collaboration and cross-skilling within the team
• To reward the top performers and manage the poor performers

This looks like a lot to ask from a single process with a simple measurement system, but I believe that the process we have selected should achieve all of these.  Firstly it is necessary to note that I have created three development teams who are accountable for progressing our technical strategy and defining standards and toolsets within their respective domains.  These are the “Front-Ends” team which includes the web-team, the Integration team, and the Services team.

The RFP Process

• At the Project prioritisation forum the Business-Unit heads agree the priorities of the projects for which we will publish RFPs
• The Project office prepares a very brief RFP describing the key outcomes required for the project.
• As the CIO, I estimate the size of the project and award the project a size-value on a scale of 1-20.
• The RFP is published on an internal blog indicating its size-value and priority.
• The developers are notified of a new RFP and may then respond to the RFP or form a syndicate across the various teams to respond to the RFP.  Only two days are allocated for the construction of a proposal at this point in the process.
• The responses are considered at the weekly Architecture council meeting (Chief Architect, Head of Operations, Heads of each development team, Data & Services registrar) in terms of the quality of the technical approach, the reasonableness of the effort estimate and the time-to-market vs architectural-significance trade-offs.
• One syndicate is awarded the project and must take into consideration any guidance offered by the architectural council.

The Planning Process

• The syndicate should then embark on a detailed estimation process which follows a Delphi methodology to arrive at a fairly good estimate of effort.
• A detailed design process is worked into the plan and after the design is complete the effort estimates are reviewed one more time.
• The project is baselined at this point and deadline targets are measured based on this iteration of the project estimation.
• Depending on each syndicate members involvement after the estimation the project-size units earned by each member is adjusted if necessary.

The Project Scoring process

• Once the project has been completed it must be scored by all the relevant stakeholders.
• A standardized electronic survey with a set of questions for each type of stakeholder is used, so that scores can be easily compared.
• The standardized questions are published so that everyone knows in advance what the required outcomes are.

The Performance  Measurement Metrics:

Using these measures the following can easily be measured and managed:

• Each individual must have earned at least 20 Project size points in a year.  I measure this on a prorated basis every quarter and meet with underperforming team members to help them get back on track.
• In order to qualify for a bonus each individual must earn at least 24 project-size points in a year.
• Of those eligible for a bonus, their individual Aggregate Project Outcome Scores  (Sum of (earned Projects Size-points x Project Survey Score) for all the projects an individual was involved in) determines their rank on the Bonus list.  Top 5 scorers earn 15,14,13,12,11% of the development team bonus pool respectively, and the balance of the eligible team-members share the remaining 37% as a ratio of their relative scores.

Performance Reporting

Although all this may sound complicated it reduces each team-member’s score to two metrics: Project Size Points and Project Outcome Scores.

• If you have more than 20 Project Size points you keep your job. 
• If you have more than 24 Project Size points you will get a bonus.  
• The size of that bonus is determined by you Project outcome Scores (The quality & timeliness of your work)

The current scores for each team member (both size and outcome scores) are published weekly for all to see.  No-one should have any doubt where they stand at any point in the year.

Some Balancing factors

Of course none of this works if there are insufficient projects to keep everyone busy during the year.  It would not be fair if there were not enough project-size points available to ensure that everyone can earn their required 20.  Fortunately I do not anticipate that scenario for many years to come.
I am sure that by the time that occurs humans will no longer be involved in software development processes, and performance measurement will have a completely different set of objectives.

• Where we are
• Where we want to be
• How to get there

In my experience IT strategies tend to get stuck defining “where we are” because the sort of people doing IT are often detail oriented people and defining the as-is becomes an exercise that spirals into ever increasing levels of detail and never finishes, or becomes obsolete before it’s finished because some other imperative forces a change before the process completes.

My recommendation is to switch the order slightly for a very specific reason.  I propose that we define IT strategy in terms of

• Where we want to be
• Where we are
• How to get there

This seems like a minor change, but there is method in this.  It is more difficult to define the future in terms of extremely fine-grained detail, so the future view tends to be defined in terms of principles, and characteristics or properties of the future state – A High level description of the future.

The trick then is to structure the definition of “Where we are” in terms of the deltas with the “Where we want to be” description.  So we shouldn’t try to define the “As-Is” in all it’s glory, but only the aspects that will be impacted by the notable differences with the “to-be” definition.

For example if we have a proprietary solution in the “as-is” and the “to-be” says we will use a commodity “off the shelf solution”, The definition of the “as-is” can be limited to the description of the critical features of the “as-is” that must be carried forward into the future solution and why.

In many future scenarios we want to add some capabilities that were never there in the “as-is”.  In this case the “As-Is” can be captured as a check-list of areas against which the new capabilities must be developed.

So the basic idea is to use the “To-Be” view as a guideline to indicate how much detail is required in documenting the “as-is”. When you have enough “As-Is” documented to be able to create a “How to get there” plan, then stop.

When the individual projects kick-off to actually implement the changes, these projects themselves can go to a greater level of detail if required.  The important point here then is to ensure that these updates of greater detail are recorded in the architecture artifacts of the organization, and not only stored with the project documentation.

I use a number of patterns or templates for documenting the “as-is” and to be.  A List of those next time.

Some great lessons, and an excellent reminder

I am excited about the opportunity and feel the weight of a great responsibility to an already successful organisation.

Strategic Alignment of IT with the declared business strategy is a topic that seems to be widely regarded as a holy grail.  Something Everyone Strives for, but seldom achieves.

In my last few roles I have encountered a number of challenges in achieving a satisfactory IT strategy:

• A business strategy that is not published or is unclear
• The desired role of IT in the business is unclear
• It is unclear who the leaders in each business unit are
• An unwillingness by IT leaders to declare a strategy – always deferring to the so-called “business”

Let’s face it, if the business strategy is clear, and is officially published, the task is not so daunting.  If however you are in an organisation that exhibits some of the above difficulties, then the task of defining an aligned IT strategy looks a little more tricky.

I firmly believe that when we are looking at the problem of an aligned IT strategy, we incorrectly try to engage our engineering skills, instead of our artisitic skills.

Now clearly there should be a balance, but I do not believe the right strategy can be defined with purely technical analysis. Lateral thinking, creative solutions, cross discipline thinking, presentation and graphic design; These are the most valuable tools.

For me, the most impactful and resonant IT strategies have been created when I have simply mulled over the business strategic problems for a period of time, and one day woken up thinking “aha – this is what IT should do to respond to those”.  I have wondered if this process could somehow be defined or mapped out, like an engineering process, but alas, lately I have come to believe it is not a process, so much as an art.  Now every artist has their own creative process, but most use the same tools: easel, paintbrush, paints etc.

So in this series I shall attempt to describe my own creative process, and also some of the tools I believe every IT strategist could employ to great benefit.

I know this blog has been dormant for some time, but I am inspired again!
2 years in the public sector are behind, and I’m back in the world of action, and results! 

next time: Tools of the IT strategist.

IT Strategy, IT Management

Also this role presents the challenge of unifying solutions across previously disparate organistions.  Something I am familiar with from my time in Stockbroking IT, where company mergers happened fairly often.

My presentation for “Help Desk & IT Service Management World Africa 2009” (whew, what a name) is coming along, and I’m hoping it will be a lot of fun, as well as giving everyone some useful thinking tools.