Complex Adaptive Systems: Why most Information Systems don’t Measure Up.

Complex Adaptive Systems, or Complexity Science, is about a lot more than Information Systems, we human beings being a prime example of such complexity. Wikipedia and other sources provide all the details you want on this topic, but one view of it that has stuck with me over the years is the difference between ‘complicated’ and ‘complex’.

Roughly speaking, a complicated system is what it sounds like, a system that is not simple and not intuitively understandable; however, given time and effort, you could analyze and identify all its parts and pieces and describe the whole system. The key is that it is a fixed system.

In contrast, a complex system cannot be analyzed and described as above because it is changing over time; analyze it last week, and again next week, and you will get two different descriptions. For decades, we have been fairly good at creating complicated information systems, but complex was and is rare, if even considered. Instead, what we have in IT is the Change Request, the Backlog, the up-coming Maintenance Release.

The problem has been our creating of information systems based on the needs of an organization at the time we asked. We were guilty of hard-coding the business process and rules (while probably not recognizing them as such) and delivered that code in working order, to be told that the business wasn’t doing things that way anymore; or worse, the business would keep this to themselves and start creating the first of many ‘workarounds’ needed to get past the system limitations and get things done. In either case, the situation would deteriorate and then the change requests would start coming.

Now, hind-sight is wonderful, and decades of hard, well-intentioned IT work should not be scoffed at; this has been a difficult realization to come to, common in many disciplines where complexity science has tussled with older paradigms; and the realization did come together in pieces over time as parts of the problem were recognized and new technologies & tools were developed to help. The now ubiquitous Database Management System came from realizing that lots of flat or indexed files processed in various batch jobs resulted in lousy information, and certainly weren’t going to work in on-line transactions, and even then we had to work our way through competing designs like hierarchical systems before the relational systems we use today emerged.

However, when it comes to complexity, data needed by a business is comparatively stable; it is how the data is used that changes more. Take a typical business process of handling a loan application; today the big loans go to Fred to process, but next week they go to Anne. That is the kind of change you cannot make to a hard-coded system fast enough to support the business. Beyond that, consider the rules that drive a process, such as loans over $100,000 need to be approved by a VP; and starting next week, it is changing to loans over $75,000.

This kind of complexity has finally led to some changes and new tools to help the business. First out of the block has been Business Process Management tools (BPM), which originated when imaging systems changed offices from moving paper around to moving units of work. More recently, Business Rule Management Systems are being implemented that move the changing of rules from the realm of the programmer to that of the business expert.

Will these tools be enough to move us from complicated, maintenance-heavy systems to truly flexible complex systems? There is no denying it will help; they will certainly solve a lot of old problems, so that we can move on to solving newer, better problems and what more can you ask for.

Once a project is started, finish it.

No principle screams from the page to me than this one, yet rarely have I seen it implemented.

I have worked under various managerial styles, but it boils down to two approaches for me, integrated or divided. All enterprises of any size do need to be composed of many organizational units, but that is to divide up the people into manageable groups; it should not divide the enterprise into separate fiefdoms. Just think how many times you have seen or been part of a re-organization, and then think about how many times that has changed the actual work you or anyone else does; the latter adds up to just about nil.

Consider a complete enterprise, with all the usual line and staff functions ; ask anyone in that enterprise how it is structured to do its business and you will probably be shown an org chart. The usual hierarchy of boxes and lines, from CEO down to the base units, is the business graphic that is the oldest and most commonly used. However, why does it have to keep changing? That’s because people are not automons, they need to be grouped in ways that maximize their contribution to the enterprise, while hopefully having job satisfaction and a boss they don’t loathe; and since people come and go, and since people can change over time, any one instance of an organization (as represented by an org chart) will be become sub-optimal as time passes, so re-organization is needed, and it is a good thing if it re-energizes people and re-marshals the enterprise to be its most effective.

The problem is when management believes that the org chart at any one time also represents how the work gets done. Worse yet, they also use the org chart as the basis for changing/improving how the work gets done. This is the ‘divided’ managerial style I mentioned earlier, and it directly affects how the enterprise carries out projects.

At any one time, an enterprise has certain amount of capacity to implement change; the main numbers are how many people there are to do projects, and/or how much money is available to hire outside people to do projects. These numbers are a primary input to that common-place activity of annual budgeting/planning; these numbers are limited/finite, so managers need to decide how to best use them. In the divided managerial style, each major tree below the CEO on the org chart is allocated some portion of those numbers; if you have 10 people available for projects, the number used may be 120 person months. So, Sales is allocated 20 months, Operations gets 40, Finance gets 35, etc. Management may come up with what it believes are equitable/effective means of divvying up the number beyond just dividing it into equal units, but that is a sham; this is further reinforced by the sham idea that if each unit operates and changes successfully in of itself, then the total of all the units’ success will equal the overall success of the enterprise. Does your company have internal charges between departments, often referred to as ‘funny money’? Then your company is divided, because all that funny money means nothing to the bottom line of the enterprise.

A divided approach is a problem when projects are used to improve the business, because projects change the work, not the organization. Take an important and common business activity, order fulfillment. If you trace the work from when a customer first orders a thing or a service, to when its delivery is complete, many (many!) org units will be involved. So, if each unit independently attempts to change/improve that stream of work, they will either overlap with other units or duplicate what other units are doing without knowing it.

The main result for IT is that each org unit will want to use its allocated resources to get its own projects done. So, irrespective of their overall value to the enterprise, a number of projects will get initiated. This will result in overlap or duplication within the systems IT delivers, assuming the systems are delivered. IT management will be faced with conflicting demands on their limited resources, so only some sub-set of the projects will be proceeding while others wait for resources. This leads to projects stopping for a while when they get to a point where they need new types of resources, and then have to start up again when those resources eventually become available.

So, irrespective of the method used to divvy up project resources, the ‘divide’ approach produces an ineffective and wasteful projects environment. The solution to this problem is to move to an integrated managerial approach.

An ‘integrated approach’ recognizes that an enterprise is a team brought together to operate a business, not a collection of independent fiefdoms; a CEO that recognizes and leverages this approach also knows that projects to improve the business belong to the enterprise, and almost always impact multiple organization units. Given this recognition, how an enterprise organizes its resources to carry out projects then will (or should) be tailored to the mix of people involved, just like any other aspect of organization. This could be anything, from ad-hoc teams to a full Project Management Office. Any good structure will do, as long as the enterprise view is maintained.

And that’s all I have to say about that.

IT Project Cost-Benefit Analysis

Assuming you got through the rough stuff of defining costs and benefits, the analysis should be simple. What you want to know is if the benefits of the project will exceed the costs, and by how much. Since costs and benefits may be spread over long periods of time, Present Values of these amounts are also usually calculated to compare the amounts in “today’s” dollars.

When I did my first Cost-Benefit Analysis for a major project, I had to work with an spreadsheet expert to to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the two dollar values, cost and benefit, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.

Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.

These calculations may be used to determine if a project passes a funding hurdle; its not enough that a project makes money, but it has to make more than investing the equivalent dollars of the project cost in securities or other investments.

After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.

How do you know which IT Projects to do? Benefits…

Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. Benefits, however, are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.

In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.

In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived this as eventually leading to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.

However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects, or projects that are expected to increase revenue/income.

The question becomes: how much will this project contribute to increased sales of products and/or services. This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.

In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.

How do you know which IT Projects to do? Project Costs

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc… The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

Estimating the cost of IT projects is a whole discipline in of itself. I highly recommend the writings of Vitalie Temnenco on this topic, such as “Software Estimation, Enterprise-Wide - Part I: Reasons and Means (June 2007), at

http://www.ibm.com/developerworks/ration… ,

where the author is described “an architect for the Ontario, Canada government’s Workplace Safety and Insurance Board, where he provides architectural mentoring on implementation projects and helps teams embrace RUP and the Enterprise Architecture concepts.”

In this article, he covers the most well-known techniques, classifying them as top-down or bottom-up, and continues on to cutting edge techniques like neural networks and Dynamics-based techniques.

My experience with estimating has led to always determining up-front how close to accurate an estimate needs to be. When using cost estimates as part of a gating process, I find a reasonably supported estimate done in a short time will suffice. I have heard an initial estimating being referred to as “t-shirt sizing”; is it small or medium or large or extra-large, etc. Even this needs some context for a company, usually by classifying past project actual efforts the same way.

This helps with the simple approach of “Is this new Project X the same size as a previous project we have carried out?” Assuming your company has kept the metrics about previous projects, and that is a big assumption, you can then extrapolate the size and cost of any similar new projects.

True, some one has to lay it on the line and decide if a new project is reasonably similar to previous projects, and the person doing that should probably define some assumptions about why they believe so. This allows the decision makers to agree with or challenge the assumptions as needed, until all are agreed on the assumptions and accept the resulting estimate.

If you have no metrics/history to use, you may need to do some project planning to define the tasks likely to be carried out. Again, a whole other big discipline exists for project planning and management, and use of techniques of like Work Break-Down Structures (WBS). A simple web search or a visit to the Project Management Institute (PMI) website will get you started on that as needed. The only thing I emphasize in this approach is that as much as possible, people who would do the work should help in defining the necessary tasks, and then they most certainly should do the estimating of effort (usually in hours or days) of those tasks. They know best what will be needed, and will make sure they are happy with the estimate because they will likely have to work to that estimate when the project starts.

This planning approach must also make assumptions, mainly about what the project would deliver that will provide the expected benefits, and that may not always be very clear when a project heads into the gating process. So again, define assumptions that the decision-makers will accept and then go from there. In the end you will have a number of effort hours or days, and then you need an accepted price for an hour or day. Some shops will use a flat rate for all hours, while others will group the hours by role or seniority to get a range of rates. In either case, you multiply the hours/days by the price(s) and you have a cost. Other costs may be involved as well, especially one-time purchases of equipment or software needed by a project.

To go along with this cost, you will need an estimate of elapsed time for the project to execute and finish, because most benefits will not be realized until a project is over, and (later on) we will want to compute a present-value of future costs. More assumptions are needed; how many people will be assigned, what work can be done in parallel, etc. If you have used a project planning approach, you will have the advantage of defining many of these things already and will have come up with a project duration along with the project effort.

How do you know which IT Projects to do? and not to do?

Any company, and its IT organization, has a limit on the resources it can use on projects, so it has to choose, and choose wisely, from all the ideas and opportunities it may have before it at any one time.

The term that has emerged to describe this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development. As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the company.

The key question then is: what projects does the Enterprise consider to be most valuable? And the follow-up: how does it determine the value of any one project, so it can be evaluated against ‘competing’ projects?

In private enterprise, the single common goal is sustained profitably , through a varying combination of revenue increases and cost reductions. Projects are used to change how a company operates in the expectation that such change will deliver the desired revenue increase or cost reduction, and deliver it such that the value of the changes is not exceeded by the cost of the project itself.

So, we have two aspects of a project that will usually be used to determine its value:

1) Its impact on revenue or costs of the enterprise, commonly known as Benefits.

2) The Costs of carrying out the project (which some refer to as the ‘investment’)

Given these two dollar numbers, which is what they should always boil down to, you can then use them in one or more forms of what is commonly called a ‘Cost-Benefit Analysis’. However, neither number just appears out of thin air, and any numbers you do come up with will never be exact, because estimating is involved.

Next time: getting Costs and Benefits for IT Projects.

David Wright

http://www.authorsden.com/visit/viewwork…

Pick The Right (IT) Projects for the Business

IT Projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show most IT projects are also usually late, and a large number are never even completed(!).

How did this happen? My view is that, way back when, computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise but, as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.

Early computer projects really were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable).

But that is the history: all the easy automation projects have long been done.

Next time: how to choose the most valuable IT Projects…

Which projects should you focus on first?

Continued from:

“Get Your Projects Under Control…”

http://businessanalysis56.blogspot.com/2009/05/get-your-projects-under-control.html

If you have too many projects going at the same time, pick the best ones to focus your resources on: but how do you do that?

If no other factors are in play, choose the projects that most closely look to be near completion. This can be difficult, given that “90% done” syndrome ; you may focus on a 90% done project and find it is more like only 10% done in reality(!), at which point I would drop it and move on to a more promising project.

Other factors can be applied in selecting projects sub-set; they depend a lot on how much information you have on your projects, and can include:

- Business Value or Return On Investment: if you already have some notion of the value of a delivering a project, especially a cost-benefit analysis, you can try attacking the projects with the highest value if that is something your business management will appreciate. Many companies are good at defining value or benefit up-front, but only the better companies take the time after a project is complete to confirm if the benefits really were realized. If you company does not do this yet, suggest they start, but avoid this factor for selecting the projects subset until they do start.

- Project Priority, which can be determined based on a combination of Business Value and/or other Project Drivers. This is often a weighted calculation where values are assigned based on how well a project addresses items such as ‘increased sales’, ‘improved decision-making’, ‘better customer service’, etc. . Each project has a priority value to compare to others, and highest-priority projects are initiated first.
If you have a Priority value assigned for your projects, but it really hasn’t been the key factor in initiating projects, then start using it; that’s pretty obvious, I know. What is more likely is that priority did play a part in initiating projects, but has not carried over to decisions made during projects. If your projects are now executing out-of-priority order, see if re-ordering them will help in faster delivery and increased business value.

- When all else fails, Ask. (Or just start with Ask). It will be no big secret if you have many projects underway with no ends in sight. It is also likely that many current stakeholders may not have been involved when some of the projects were started. So, you can meet with these stakeholders to determine what their current priorities are and which projects are of most value to them.
The usual issue with this approach is: who should I ask? In a perfect situation, I look for the person highest in the organization whose span of control covers all departments who sponsored or are impacted by the projects. However, this person could be senior enough in the company that they may decline to help you, preferring to delegate to their reports. Querying and meeting with this group may give you the priorities you need; or, it may illustrate any politics or power struggles that are on-going, for which you may be able to facilitate a resolution or at least a compromise…or not. In the latter case, it may be necessary to escalate this back to groups’ common manager for resolution.

So, one or more of the above factors may assist you in identifying the best sub-set of projects to first target for quick completion. If no strong values or priorities can be discerned, I would default to those that can finish the fastest.

Get your projects under control...

In these trying times…or some variation of that…is the first line in every other article or post of the past 6 months, and I am getting really tired of it.

What usually follows is advice to get things in order, whatever the thing of interest is, while focus is elsewhere and before it turns back to you. However, if your thing of is interest is the slate of current IT projects in your organization, there indeed may be some opportunity here. It’s time to get positive.

Do you have a lot of parallel projects? Probably figgting for the same more limited (than ever) resources? Are they all target-date challenged, i.e. all late or later than late? Now is the time to get them under control.

The absolute first priority is to wind-up as many of these projects as possible, as soon as possible. This sounds like common-sense; it is certainly sensible, but not at all common.

No rocket-science here, you need to allocate all your resources to a subset of the on-going projects, get some successful project deliveries, and then look around for new opportunities. If you have a large slate of current projects, you may need to do this again (and again) for another subset of projects. Keep doing this until the number of current projects no longer exceeds your capacity to resource them, or as close as you can get. Do your utmost to avoid initiating any new projects while cleaning up the current projects.

(Of course, some projects cannot be delayed, especially changes needed for new legislation or other compliance issues. Jump on those immediately and get them done quickly so you can get back to the other on-going projects.)

It also helps if you can manage to identify any existing projects that can be canceled out-right. This will not be totally in your control, as the business unit or sponsor that wants the project done may resist. It is just to your advantage to identify any projects that are clearly no longer needed, and who’s sunk costs should be capped.

How many projects should you focus on as described above? You can’t overload a single project either, without incurring diminishing returns. A rule-of-thumb would be to define the number of people on a typical project team in your shop, and then divide that number into the total number of people you have available for projects. There are many ideas and opinions about optimum team size, usually around 7 plus or minus 2.

Next time: which projects should you pick first?

IT Projects Success - Principle #13: Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.
In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

IT Projects Success - Principle #12: Within the three month phase, parcel work into two-week periods.

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

IT Projects Success - Principle #11: Partition large projects into 3 month phases

Continued from:

http://blogs.itworldcanada.com/insights/…

(Want to see more? head over to http://bit.ly/Ypycy )

11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

I was lucky to learn this early in the 90’s as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, “A plan is only good until the battle is joined.” After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing, we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was about this time that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

IT Projects Success - Principle #10: Models are better than text.

10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

(see more at http://stores.lulu.com/dwwright99 )

IT Projects Success - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave.

9. Leave a record of what you have done, so the project will not miss you if you leave.

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in #8 above, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Last Chance to Participate - Business Analysis Benchmark

This is your last chance to participate in the 2009 Business Analysis Benchmark study - and access your copy of last year's research. Last year, this research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year's theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CPC1M/61635542

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-20/CPC2Q/61635542

IT Projects Success - Principle #8: It’s the Deliverable (that matters), not the Task.

8. It’s the Deliverable (that matters), not the Task.


The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.


This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.


What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Can IBM automate decisions? Sure, it's already happening.

News post: Algorithms everywhere: Can IBM automate business decisions?

http://blogs.zdnet.com/BTL/?p=16345&tag=nl.e019

see “Smart (Enough) Systems” http://www.smartenoughsystems.com/ by James Taylor.

This is not about automating decisions made by people, it is about automating decisions that don’t need people. Dig deeper, and this is about Business Rules. In situations where all responses to a question can be defined depending on data about the situation, having people pick an answer is a waste. Biggest example? Credit Checks and your Credit Score, and ‘deciding’ to approve a request for credit. This is being done thousands/millions/whatever times per hour/day, and there not enough people available to do this.

Why do you think IBM bought iLog? Advanced companies already do this. Insurance underwriting is another big domain.

And this is never going to be about Artificial Intelligence. Smarter systems are made of the same stuff as ‘dumb’ systems, they just know more, enough to make a decision based on facts. If the facts aren’t available, the system is not going to ‘think’ or ‘reason’ its way to a decision, its just going to ask for the facts, please.

AS-IS versus TO-BE

Have not seen a great methodology debate (without the word 'agile') for ages. Here is one over at Modern Analyst, with my comment already added: http://bit.ly/WNLN

IT Projects Success - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester

7. One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of Principle #6 to form the strong basis for the Cascade effect covered in Principle #13. … so stay tuned.

2009 Business Analysis Benchmark study

IAG Consulting ( www.iag.biz ) is conducting its 2009 Business Analysis Benchmark study. I invite everyone to participate, as last year’s research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year’s theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CI49E/56513172

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-01/CI4AI/56513172