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

IT Projects Success Principles 3 and 4

IT Projects Success - Principle #3: Use Architecture to describe the business, before and after projects.

Continued from:

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

3. Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman.

(see www.zifa.com for details)

He devised the illustrated matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems.

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions. Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

---------------------------------------------------------------------------------------------

IT Projects Success - Principle #4: Pick the right project(s) for the business.

Continued from:

http://blogs.itworldcanada.com/insights/2009/03/20/it-projects-success-principle-3-use-architecture-to-describe-the-business-before-and-after-projects/

4. Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.

I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before?. The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.

So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.

IT Project Success - Principles 1 and 2

#1. There is always more work to be done than people to do it.

http://blogs.itworldcanada.com/insights/2009/03/17/it-projects-success-principle-1-there-is-always-more-work-to-be-done-than-people-to-do-it/

#2 . Projects change the business, so know the overall business first.

http://blogs.itworldcanada.com/insights/2009/03/18/it-projects-success-principle-2-projects-change-the-business-so-know-the-overall-business-first/

David Wright

IT Projects - Success with Principles

Over at IT World Canada:

http://blogs.itworldcanada.com/insights/2009/03/15/it-projects-success-with-principles/

More IT World Canada

http://blogs.itworldcanada.com/insights/2009/03/12/does-this-sound-like-your-it-department/

and

http://blogs.itworldcanada.com/insights/2009/03/12/what-can-you-change-in-your-it-department/

Start of posts for "Cascasde"...

I'm Baaaaaack....

OK, I am reviving this site, to sync up many other places I am deposting content around the web, starting with

http://blogs.itworldcanada.com/insights/2009/03/08/the-myth-of-changing-requirements/

Thanks to Shane Schick at IT World Canada for the opportunity to post to Enterprise Insights.

Last post on this Blog

I have two new blogs going at http://www.ittoolbox.com/profiles/DavidWright and http://www.requirementsnetwork.com/blog/307

Check them out!

After the kick-off.... Zachman and Requirements

Given the time I had to prepare for the Requirements sessions, they actually came and went without any big surprises. I met with different groups of end-users, usually by the Role/Job they performed, and fleshed things out here and there. I also met separately with Management about future changes to the business; that was tougher but the artifacts I had did show the differences that that would be needed in the future (essentially new Roles and more locations).

After that, I did have to reformat everything into declarative Requirement Statements, and re-group them into function, data, technical, and other categories; that's the way the current methodology arranges things when presenting to senior management. So, all the content was there, you just have to be ready to present it in different ways depending on your audience.

...and the audience yesterday was senior management on a steering committee and, six hours later, all was received with approval and appreciation.

As usual, the run-up to this review with senior people was tight, took lots of hours, and IT management had two other analysts come on to help meet the review date. So, there were some long work-days, including while I was down DC, but it was worth it in the end.

Next Up: massaging the Requirements into a standard RFP format and getting it out the main vendor we are dealing with...

David Wright
Member, IIBA
"The waterfall is not too long, the river is too wide."

OK, I am back from the Business Rule Forum...

...and as usual, I have lots of notes and material and stuff that I don't know when I will get a chance to sift through. I may have more to say in later posts, but for today:

- Business Process Management working in sync with Business Rules Management was the common topic/theme of the conference

- I did my own presentation on "Integrating Requirements Artifacts" which included BPM and BRM with function and data, etc.; got a good response. Again, if you can manage public speaking, and have something to say, submit something to a conference of interest to you, it is great fun...really...

- lunch and sponsored events where you can meet other attendees and exchange info/stories are just as valuable as the conference sessions

- this was my second year at this Forum, and I like it especially because it attracts a mix of both Business and IT people... and the vendors are there too, of course.

- Washington DC is pleasant this time of year, mild with some rain, leaves still in fall colors; being there on election day added some flavour to the week as well. So, not all conferences have to be in Vegas, Phoenix, or Orlando to merit your attention(!)

That's it for now...dww

Practical Use of the Zachman Framework For Organizing Information System Requirements: Part 3 - Matrices

Finishing off my Row 2 artifacts, one thing that came out was that list of 40 to 50 candidate Use Cases. For my business audience, I have started calling them System Use Cases, so there was no ambiguity; these are the required ways to be able to use a solution/system. So, I think I have decided that these are row 3 artifacts, but they also remain in the People/Who column.

Having this list leads to my first cross-reference matrix, ‘User Role’ to ‘System Use Case’; this will be very handy in illustrating who can do what, and just as importantly, who can’t do what.
I am also finding it useful to xref the System Use Cases to the lowest levels of the Functional Decomposition, as mentioned and discussed in my earlier post. I am not sure yet what else the decomposition brings to the overall requirements; certainly many past methodologies used decompositions to get to the lowest level definition of functionality, and after that the higher levels were not used any further in the Requirements.

Another small but illustrative cross-reference is “User Role” to “Location”; from this, one can derive what System Use Cases would be performed at a Location. This is going to help going forward as it is already expected that the new system will be used at more locations than the current systems. This may also include defining some new User Roles as well, which will then drive the questions: “Which System Use Cases will this new User Role need to use? Do they need new System Use Cases?”

For my own satisfaction, I also worked out the classic “Data Entity” cross-referenced to “Function” (Use Case, really), and then manually performed Affinity Analysis to see if any different ‘subject areas’ were revealed. Since the business scope is really about one major entity, a Credit Application, the analysis essentially confirmed that. However, it also organized the functions around the its dependent entity types as well, so one can see how these groupings could possibly lead to de-coupled definitions of sub-systems or components… but that’s for the Developer/Architect to surmise!

And so… that is pretty much where I stopped in creating draft requirement artifacts before heading into requirements sessions with the business. Overlapping with the beginning of those sessions, I did consider what other Row 3 artifacts still might come into play in creating an overall requirements definition.

My current thoughts on Row 3 have been greatly influenced by having recently read “Requirements Analysis: From Business Views to Architecture”, by David C. Hay (Prentice-Hall, 2003). This book does two main things (and some others, too) that helped me:A) It reviewed that past 50 years or so of methodologies and artifacts, and categorizes the artifacts by Zachman Cell; even without that categorization, this is a great piece of IS history that I have seen nowhere else, thank-you Mr. Hay.B) It re-focuses Row 3 from the Designer View to the Architect’s view, and within that classifies Row 2 artifacts as ‘Divergent Models’ and Row 3 artifacts as ‘Convergent Models’, which I found powerful.

The best example of (B) is in the Data Column: your Row 2 model may have entities for Customers, Suppliers, Staff, and the like. Given that, your Row 3 model would be based on a Party/Relationship Model, where all the participants in the business (and new ones when they are defined) are supported by one common, flexible data model, and the data structures you would create from that model. Some call these meta-models, but I avoid the term with business people for the most part. So, the other columns may also have such convergent artifacts, such as Workflow models for the Function column, and Business Rule Models for the Motivation column.
I have still been working on these Row 3 artifacts as I have also been gathering mainly Row 2 level information during Requirements sessions with the business. So, my next blog entries on this will be about what happened in those sessions. It might be a while before I get to posting those, but they will come…

Practical Use of the Zachman Framework For Organizing Information System Requirements: Part 2 - Business Model

Row 2

The Zachman Framework is notable first for being just that, a framework for different approaches to use to organize their artifacts; further, some writers have customized the framework to rename some of the rows/views. Despite this, Row 2 is still mainly about the Business specifics, be it the Business Model (conceptual view), or the Business Owner’s View. I am going to use the original “Business Model” terminology for Row 2, but may diverge when I get to Row 3…

As I write this part of my article, I have finished using all my source documents to flesh out a Business Model that I can take into requirements sessions with business staff and various subject matter experts. Those will be taking place shortly, so I expect to add to this article after the sessions, to document the experience and analyze for myself how much variance exists between my draft Model and the Model after the sessions.

Let us start with each cell in the row again, but after that, I also have some column-to-column cross-reference matrices that I expect to help me in actual analysis and validation of the Model as a set of Requirements.

Row 2 (Business Model) and Column 1 (Data / “What”):
The scope of this project is a major process of the company, one of five that have been defined. So, what I found is that the 14 things of interest I defined in Row 1 were not Subject Areas with many entities to discover; the business process is mainly concerned with the life-cycle of one core entity type and its dependent entities. At this point, I think I can identify that this core ‘thing’ is a Credit Application without revealing any proprietary information. The rest of the 14 mainly equate to single entity types as well, which fall into the following three categories:

o Entities for data that exists for the process to use but does not maintain, such as Product data,
o Entities for data that are dependent on the Credit Application, like the items/assets being financed (although these may turn out to be independent entities from a wider enterprise perspective),
o and Entities for data that is created by the Process that is used downstream in the business, like contract and account data.

Further, just applying 1st normal form would drive out a few more entity types, but I don’t think this is absolutely necessary in row 2, especially depending on your business audiences comfort level with ER diagrams. The business participants at my company are, as I have described, very comfortable with process flow models from six sigma process improvement efforts, but data models are unknown, and my previous use of them in smaller projects has been met with indifference. As a result, I expect to use an alphabetical list of entity types, with list of attributes for each one, all in business terms; relationships will have to be covered as statements, but business rule formats can help that (see column six).

I do have a lot of attributes already, given the detail in the process maps, current systems, and those previous data models. I have not started to define the attributes yet, many definitions already exist in current systems and glossaries, but I do plan to build a Glossary of Terms for this project in the sessions as needed, especially to document aliases, and resolve different uses of a term.

Row 2 (Business Model) and Column 2 (Function/ ‘How’):
The existing process maps relate to the six ‘boxes’ of the High-Level Process Map almost 1 to 1; however, they are several layers more detailed, each map having 40 to 60 steps, many decision points (diamonds) and dependence on use, and limitations, of existing systems. At this level, process maps are too detailed and too volatile to be useful information system requirements, so I tracked back to the six ‘boxes’ and started a functional decomposition. Groupings of process steps coalesce into more stable functions, and I derived a small functional hierarchy, no deeper than three levels, with about 20 root-level functions. At the same time, some of the process steps look like candidate use cases… or lowest-level CRUD functions.

Here I return to my previous thoughts that Column 2 has the most artifact choices, and I have been looking at process maps, a functional decomposition, and use cases… but looking ahead to column 4, some say that use cases are a Role/User artifact, and maybe they are Row 3(?). Perhaps those are the ‘concrete’ use cases as defined by RUP, but RUP also supports conceptual use cases for analysis of a domain before design. I do expect that I will end up with use cases as part of the Requirements, if only because they are a common artifact that my business users have seen in earlier projects, but at this point in the project it will may actually be a list of use case names and short descriptions; detailing them would come later after selecting the solution approach.

Use Cases can be considered as artifacts that span columns, as they (at least) document roles through Actors, and system activity. Again, the Framework does not dictate artifacts, so it is up to the analyst to categorize artifacts into the framework in the way that works best for capturing the business model, and then communicating the model as well. It is interesting that if one does categorize use cases as column 4 artifacts, I can see how it is useful to cross-reference them back to the root functions of the decomposition in Column 2.

Row 2 (Business Model) and Column 3 (Network / ‘Where’):
This cell is very skimpy at this point for my project. Is it because the ‘network’ is ubiquitous? Maybe, but the one thing one can highlight here is that the various locations communicate in multiple ways that might fall within the scope of an information system to manage.

This starts with good old snail-mail, and its rabbit cousins, the various express couriers. Even in the latter, the recording media is paper, which has not gone away; the ‘computer network’ as most perceive it does not assist with this communication (unless you count checking the status of your delivery at a courier company’s website).

A close parallel is, of course, the fax machine, which has been with us since the 1930’s. Again, a business’s own network requirements will probably still assume the perceivable separate existence of a voice network which can transmit faxes.

(Here’s my tech question of the moment; is anyone using VOIP to send faxes, presumably to take that cost off the long distance bill?)

… but what if paper documents are scanned to create PDF files? That can then be sent by email, or uploaded/downloaded inside a company’s VPN using Portals, and all that? Does that unstructured data file need to be managed by the business’s information system(s)? That’s one question I will be asking in this project, along with older-style imaging and document management. I can see how the requirements emerging from these topics will end up back in column 1, since not all data of interest to the business can be recorded as zeroes and ones.

That leaves email (in general) and voice communications between people at different locations, or within one location as well. I have already seen newer transaction systems being augmented by management of emails related to a transaction, especially in systems where transactions are generated by a field sales force and sent to a head office for completion. As for voice communications, we are all familiar with the phrase “your call may be recorded for training or other purposes”, which will be managed by customer call centre systems. Will recording and management of phone calls move beyond the call centre, and be part of transaction systems? I can’t see why not.

As I move into the requirements sessions with the business for my project at hand, I do already know that fax is still expected to be a primary means of communicating between any and all locations; everyone we do business with, within or beyond arms-length, will accept a fax and has a process for dealing with them when they arrive; that still can’t be said for email even at this state of its maturity.

Row 2 (Business Model) and Column 4 (People/Roles, or ‘Who’):
At this point, I think the Roles I had in Row 1 probably belong in this cell, with an overall Org Chart in the Row 1 cell; or, Use Cases are a Row 2 artifact. I am not overly concerned with the specific Rows, right now, only that I have the Roles that are going to be Actors in Use Cases. Again, maybe a list of candidate Use Cases is something to gather at this level, and they do appear to match to system-related steps in the Process Models.

Row 2 (Business Model) and Column 5 (Time, or ‘When’):
In this cell, I have looked at Entity Type Life-Cycles as the time view on key data. In this process, there is the one major entity type, Credit Application. The basic states are ‘submitted’, followed by ‘approved’ or ‘declined’, with a few other states mixed in for control.

Row 2 (Business Model) and Column 6 (Motivation, or ‘Why’):
As mentioned before, I already have collected a set of company policies, from which I can derive specific Business Rules. It was a this point that I dug out some previous R&D work I did on Business Rules a few years ago, with many of the Rules being related to this project’s business process. Again I am wondering, are the Rules a row 2 or row 3 artifact? I think this will resolve itself as I examine Row 3 completely.

Next, Row 3? Or Cross-Reference Matrices?
Row 3 on the Framework is noted to be a Designer’s view, but I have also seen some writers show Requirements artifacts in Row 3 of some columns, so I expect to look more at Row 3 next time, including the issue if whether Row 3 is simply a translation of Row 2, or if it the move from 2 to 3 involves some transformation as well.

I also have some of those matrices coming along, will have to see how to describe those in blog format…

Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope (cont.)

...continuing from previous post.

That is just how I started, either gathering or copying existing content as needed. My main source was the Six Sigma process models, which in themselves can be a row a Two Process Artifact. They also typically show Roles, Items of Interest, Inputs , Deliverables and more, so populating the other columns can be started from these maps.

So, lets begin with…
Row 1 (Scope) and Column 1 (Data, although some writers prefer ‘What”)
I now have a ‘List of Things that are Important to the Enterprise.” It contains 14 items which, as expected contain items such as Customers and Products, and other things more specific to the in-scope process of the Enterprise. A data modeler would certainly look at this list and suggest they are all major Subject Areas of the Business, from which data models may be detailed. (I am going to be purposely vague about the specifics of the process, as I in no way wish to describe proprietary and private aspects of the company.)

Row 1 (Scope) and Column 2 (Function, or generalized to ‘Activity’, along with ‘How’ to align with ‘What’ above ):
This cell, and the rest below it in this column, are prime examples of one of the main concepts of the Zachman Framework; it organizes your artifacts by resource and perspective, but does not dictate the artifacts to use. Back in Column 1, the ER Data Model is pretty much the default, irrespective of some people still trying to use UML for persistent data requirements. Here in Column 2, there is some variety of choice, so you have to choose an artifact. A company may already have a standard, usually within a Methodology. I am finding you may need more than one to capture all aspects of ‘Activity’.

For my Feasibility Study, I have located a high-level Process Map that was used in a similar project in another country (my employer is a unit of a multi-national). It is six sequential boxes. In that sense, the boxes could also be the first level of a Functional Decomposition, so I have not decided yet which kind of artifact it is(!). In any case, the existing detail Process Maps can be cross-referenced fairly directly to these boxes/ functions, which will help greatly in subsequent rows.

Further, I have indications at this point that the Business Process Scope includes or interacts with Processes located at other sites or performed by other parties, e.g. the manufacturer of items being serviced by my company’s business process, and retailers of the items being serviced as well. Some half-dozen low level steps performed by these parties are shown the Process Maps, so I am listing these as other Row 1 functions, at least to start.

Row 1 (Scope) and Column 3 (Network, or ‘Where’):
The first and main location is the head office for the unit providing the service. As mentioned, other locations will include one (maybe two) locations for the product manufacturer, and many retailer locations (100+) as well.

The other interesting location of note is ‘mobile’. My unit has a sales team that is organized by geographic regions, where those team members are located and spend a lot of time visiting retailers, so they need to be able to carry out their functions from wherever they happen to be at a point in time. Yes, using the Web to connect our ‘traveling sales mean and women’ is pretty much a given, but treating ‘mobile’ as a location at the scope level illustrates its importance.

Sidebar: As far as I know, I don’t have to deal with physical locations that move; I worked with an insurance data model once that allowed P&C companies to insure buildings on the Arctic ice-pack, which moves about(!).

Row 1 (Scope) and Column 4 (People, or ‘Who’):
This column does not have any commonly used artifacts beyond the ubiquitous Org Chart. I do think its good to have the latest one on hand when you start, knowing that it will change, and that it will not really be used as you model your business in the way needed to support Information System Requirements; but you do need to know the names and titles of the people impacted by the Information System(s) that will eventually be delivered.

For this project, I am populating this cell with about a dozen different Roles played by various employees and other participants in the Process. I picked these up right from the swim-lanes of those detailed Process Maps mentioned back at the beginning of this article. One thing of note is that Role ‘names’ don’t match to current job titles, but past experience has shown that titles come and go, but basic Roles remain.

Row 1 (Scope) and Column 5 (Time, or ‘When’):
I am using this cell to list the major external Events that the in-scope Business Process must recognize and respond to. Again, the detailed Process Maps are the source for these Events, and there are actually only two. Each one fires process executions of some length, with a lot of internal events or hand-offs, but I am not concerned with the latter at this level.

Row 1 (Scope) and Column 6 (Motivation, or ‘Why’):
I am looking forward to driving down this column to the detailed Business Rules, but at this level, I have gathered already well-documented motivational items: Company Core Values, the Mission Statement, and Strategic Goals. I have also already gathered the appropriate company policies for row 2, but more on that later.

So, that’s what I have for Row 1 at this time, based on existing available documentation. When the project starts officially, the first thing to do will be to review these definitions of scope with the Business participants, and have them confirmed or adjusted as needed.

I am also well into creating Row 2 artifacts based on the available documentation, so I will write about those in future posts...

Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope

I am doing some pre-project gathering of Requirements for an upcoming Feasibility Study to implement a new systems solution for my employer’s main process for delivery of its services to its customers. The scope and options of this study were drafted, debated and changed, until they basically aligned with my favourite phrase:

“Re-Use before Buy, Buy before Build, Build for Re-Use.”

Some even earlier pre-work to the Study has already identified several alternatives across the Re-Use and Buy options, so the study will evaluate two most ‘popular’ alternatives in order to select one as the recommended solution approach. It is possible, though not probable, that neither of these two alternatives will be recommended, after which we will move on to other identified alternatives.

So, here is what I have in terms of existing documentation to help me draft some Requirements before working with the business;(I hate a blank page as a starting point):

… Detailed Process Maps of the Business Process created by Process Pros in Six Sigma improvement projects.
… documentation on current systems (implemented before I joined the company), and my own experience on a couple of fix and enhancement projects on those systems.
… as an application, the main current system is somewhat unwieldy; I have been told it was developed based on an even earlier system without much user involvement, and was implemented before it was finished, not a great start.
… on the other hand the data model and physical database used by the application is very good, pretty much in 3NF that I can see; it was developed separately from the application, and the application is worse off because of this.; but the detail data requirements that will eventually be needed will be able to draw much from the current model and database, but this will be after the Feasibility Study.

The Feasibility Study will define high-level requirements, considered sufficient to evaluate alternatives. I have often seen such High-Level Requirements delivered as pages and pages of Requirement Statements: “the System/Solution must (do something, store something, etc.)”. The quality of a group of such statement can be very high, but the volume makes them hard to manage.

As a result I am going to use the Zachman Framework (www.zifa.com) as way of , having gathered Requirements in some form, to document them using various models/artifacts, and organize them by the rows/columns (“cells”) of the Framework. I have yet to decide if I will eventually extract a list of Requirement Statements from the artifacts, but it is quite possible I may need to so in order that a wide audience can review the Requirements without having to understand ER Models, for instance.

From a Business Analysts’ perspective, we are talking mainly about Row 2 for Requirements artifacts, what David C. Hay calls the Business Owner Viewpoint. However, if Row 1 (Scope) artifacts don’t yet exist for the business domain to be analyzed, it is best to create them for reference; the Row 1 content may already exist in various places and forms, but gathering and documenting in Row 1 is a good place to start the requirements activities for a project.

That is just how I started, to be continued...

I start some vacation today...and boy, do I need it.

Has anyone ever distributed a Requirements document/deliverable to a team to get feedback (or prepare for a walkthrough), and have the main business user instead send back an edited version of the document with the changes they want, and then demand that it be the version reviewed by the rest of the team, or then flatly state that their version is the final version to be created, and signoff their own version?

I know that's a long question, but it reflects my exasperation with recent experience. I don't want to say more publicly at this point, but I have privately written a description of this experience, mainly so I could get it out of my head and move on. Its a fine piece of writing, IMHO, and I may share some of it at a better time, allowing for some distance first.

In the meantime, does anyone have any similar 'war stories' that they want to share? I have only one from the past, as follows:

In 20 years of Requirements work, I have only ever had one ‘User from Hell’, an underwriter at an insurance company where I worked 10 years ago. While gathering CRM requirements with 3 business people, using multiple day-long sessions, this person complained/whined about why this needed to be done, and would not accept questions about the business; she just wanted us to blindly accept her input as the Requirements. I eventually turned her attitude around on this, to the point where she was presenting/defending the Requirements to other people outside the Project. However, when a new phase started for which requirements were needed, she now thought she could do all the Requirements and documenting herself, and would not meet with me at all;. I escalated this to the joint Project Managers, one IT and one Business (which actually worked well...) and they decided that since the underwriter was a long-time employee and well-known for being stubborn, they would let her go ahead while I started work on another phase that did not involve this person. Well, the results were not good, and I had to re-work everything in time to meet the target date. At this point, the underwriter was just mainly silent but did answer questions when I had them. I didn't know whether she had grudgingly accepted the situation, or would suddenly 'go postal' on us.
Anyway, I had already been looking for another job for totally un-related reasons, and left soon after this all happened. The project was slotted to go on for another couple of years, but within a year, the company was taken over and absorbed by one of the really big insurance companies, so I don't know what happened after that. Underwriters are always in demand, so I know that my 'user from hell' probably survived it all or moved on as well.

OK, now its your turn.

Free membership at Requirements Networking Group

Was just at http://www.requirementsnetwork.com/ , and the main page has a button to get free membership (for a limited time, it says). So, I recommend anyone reading this post head over there and join up, ASAP!

Requirements Networking Group, and other stuff...

If you are reading this for the first time, and/or have been here before, do leave a comment to let me know if anyone is reading this.

I have also been blogging over at http://www.requirementsnetwork.com/ as well, re-working some previous posts from this original blog and waxing on about other things; one thing it tracks is how many people have read your entries. There is also a good forum section, and some notable people are using the site, like Alastair Cockburn and David Hay. You need to join the site, which has fee, but leave a comment here saying you would like to join, and provider a little info about yourself, and your email,... I can send you an invite to join free.

Speaking of David Hay, I am reading through his book that I mentioned in an earlier post, "Requirements Analysis: From Business Views to Architecture". The meat of the book is a chapter for each Zachman Framework column. As expected, Data and Process columns have a lot of material and model types, but his chapter on People starts with saying there are virtual no common models for this column;so, he looks at Beer's Cybernetic models as a method for documenting how an Organization works as a system, made up of lower-level sub-systems. I think I will be reading that chapter again to absorb more, if I can.

I think I said earlier that I would review this book, but at the halfway point I think can succintly praise it as a book I wish I had written(!).

That's all for now...

Optimal Trace: Analysis or Design Tool?

I got the following email today, about the Optimal Trace product for Compuware. It is marketed as a requirements tool, but it looks more like an external design tool. Has anyone used this tool?

Hello David,
The Optimal Trace (formerly SteelTrace) product primarily covers the front end of the application lifecycle, that is the activities concerned with gathering, documenting and managing the correct and appropriate business and technical requirements in a structured fashion. It forms the foundation for the downstream activities of design development and testing. Therefore Optimal Trace is primarily used in analysis and then forms the bedrock of the 'contract' by which design, development & testing is conducted. Other of the Compuware family of products such as OptimalJ, DevPartner, QACenter etc. support these other phases of the lifecycle. I've attached an information sheet from the Optimal Trace website at www.compuware.com/products/optimaltrace/ for your reference. It should help you understand the value offered.
You can get other downloads at: http://www.steeltrace.com/support/downloads.php TRIALS. You may download Optimal Trace and receive a 15-day trial license at http://www.compuware.com/products/optimalj/1797_ENG_HTML.htm. RECORDED WEBEXs.
You can get a real good feel for Optimal Trace by viewing recorded product WebExs at http://www.steeltrace.com/products/demo.php. I will follow-up with you within a few days, but do not hesitate to contact me if you have questions or need clarification.

Sincerely,
...................
Java Development and Performance Management Inside Sales Representative
Compuware Corporation www.compuware.com/products

OK, no more rants on Agile from me...

I posed the issue about Agile saying "don't do requirements up front, because they will change" in a forum at http://www.requirementsnetwork.com/ and Scott Ambler himself weighed with the best answer yet on this, so go on over there and check it out. An email conversation with Peter Coffee has also helped me a great deal.

My conclusion is that originators of Agile did not see it as Extreme, but rather as Flexible; that I can understand. So, no more rants from me on Agile... but now I want to what in our profession is still bugging everyone out there. Please leave a comment, and if i get enough stuff, I will publish a "top ten' list.

Agile, Schmagile...

Here's an email I got from the Yahoo Business Analysis group I belong to:

From: "ginitram" <ginitram@yahoo.fr>
Reply-To: agileanalysis@yahoogroups.com
To: agileanalysis@yahoogroups.com
Subject: [agileanalysis] Article on Agile Adoption at British Telecom
Date: Wed, 26 Jul 2006 10:53:37 -0000
The Methods & Tools newsletter has just released in its archivesection the article "Agile Delivery at British Telecom". This articledescribes the approach used by British Telecom to move towards anAgile development process
http://www.methodsandtools.com/archive/archive.php?id=43

First, I recommend joining the group, it has a medium amount of intersting activity.

OK, here was my reply:

Hasn't this been published somewhere before? It looks familiar.

First, it's time that Agile proponents know that everyone gets it, smaller is better than bigger, delivery something on a regular basis is better than a big bang at the end of the project,... enough already. As I have said elsewhere, it's not that the waterfall is too long, it's that the river is too wide.

Ok, here are some snippets with my comments in brackets:

"Capturing requirements certainly isn’t a bad thing (well, duh). On typical large programmes however,
- Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release (sure, so the business must define the $ benefit of their pet requirements, while IT estimates the $ cost, and then present results in a cost-benefit analysis to the Sponsor, the one who is paying for the system, and it will be clear waht is in and out of the first/next release)
- "Gold users" generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed (same answer as above, plus if you literally get hundreds of requirements, declarative statements I presume, then you need to partition the project)
- Most if not all requirements are given a high priority (so rank them by highest return on investment)
- The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented (good analysis include stability analysis, documenting potential business changes and how the system will accomodate change. A systems' ability to incorporate change after delivery is also a requirement for all projects).

Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
-The requirements analysts move on to other projects, taking with them important tacit knowledge (this reflects poor documenting standards, all knowledge gathered by the Analyst must be documented.)
- Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs (what raises the stakeholders concerns? In any case, requirements are to be traced through design and into testing, so stakeholders really know what requirement is being supported where...)
- Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyses (this is scope management, the first evaluation of a change request is to determine if it is in scope or not. If it is in-scope, can it be added to the release without material impact on cost or delivery date? If not, this should go on a change request list for re-consideration in the next release.)

That's all I have to say right now...dww

New site for Requirements practitioners

The Requirements Networking Group at http://www.requirementsnetwork.com/

I have just had an article published on the site, and have started a new blog there as well. I am going to keep both going for now, with the new one re-publishing some of the material from this blog that is relevant to the site.

So, follow the link, join up and participate in forum discussions and blog responses and all that good stuff.

...in which Peter Coffee replies and we start an interesting conversation.

Peter C was gracious to reply to my slightly flammable email, starting with:

> Oh, and please give the word "Agile" back to the English language

It wasn't me who appropriated it...

- Peter

...which I answered with:

Yeah, perhaps I should re-direct that to Scott Ambler. The last time I saw him his advice to Business Analysts was "Learn how to code...".

My other question about Agile is technology selection: when do you determine that the new system will be developed with the technology at hand, presumably the languages and such that the programmers are already using? At what point does Agile say "maybe we should buy a COTS solution"? How does Agile recognize that the solution may not be new software but use of generalized infrastructure options like Workflow/BPM tools, or Business Rule Engines?

I have seen other writers' descriptions of Agile as falling into the characterization of "If all you have is a hammer, everything looks a nail". Thoughts on that?

..which he replied to with:

> At what point does Agile say "maybe we should buy a COTS solution"?

One of the principles of agile development is that "Simplicity--the art of maximizing the amount of work not done--is essential." I would certainly interpret this as implying that a team should consider available off-the-shelf packages, or externally hosted services, as preferable alternatives to writing new code.

> How does Agile recognize that the solution may not be new software but use of generalized infrastructure options

The Agile label's full expansion is "Agile Software Development," not "Agile Systems Construction." I see no reason why a systems development process that includes a development team following "Agile" practices could not also include a dynamic, collaborative uber-team that's looking at other options besides writing new code, but we should be fair to those who use the "Agile" label: they're trying to solve the genuine problem that writing new code is a task that needs to be done better, not the equally genuine but much more general problem that defining problems and developing solutions needs to be done better.

...which I liked very much, as it may clear up some confusion on the topic. I am going to reply with a follow-up, will post it later...

Today I give an Enterprise Architect some advice...

Greg Fullard is starting a series of articles about 'Business Objects" (conceptual ones, not the BI software) in Object Orientation at the IT Toolbox blogs,and he is a good writer. See:

http://blogs.ittoolbox.com/cio/modeling/archives/how-to-design-beautiful-business-objects-part-1-10718#

But he has a question I felt I could answer:
"Aren't these business objects that I keep talking about just the same as the Entities that my grandpa used to tell me about?"

The simple answer is... No.

Object Orientation has always been about producing better software, easier to maintain and primed for re-use. Entities, Relationships and Data Modeling in general has always been about producing better databases, usually (if not always) relational databases that eliminate data redundancy and are accessible without physical limitations (like old hierarchical DBMS's).

Where OO and Data Modeling look the same is their focus on key items of interest to the domain (business, government, non-profit, etc.), so good models will likely have the same-named things in them, like Customer. So what's the difference?

1) A Customer Class in OO is usually focused on one occurrence (Object) at a time, and the behaviors associated with it. A working OO system instantiates at object at some point, some methods (behaviors) are exercised, and then the object is gone. The only wrinkle on this is OO's recognition that some Objects are persistent, that they may be stored somehow and be used again.

2) A Customer Entity in a Data Model is usually focused on defining all the data attributes that need to be stored for any and all occurrences of Customer for the domain. As a blueprint for a relational table, the focus here is on managing many occurrences of Customer, as many as the domain needs to keep track of.

So, two different models, because they are two different things. The interrelationship between them occurs when a persistent Object needs to be instantiated; where do OO systems get that data? Far and way it is from relational databases, since I have not seen a (commercially) viable OO database yet.

So, two different models, and don't believe anyone who says a Class Model and a Data Model are equivalent, they are not... but you can derive a Class from an existing data model. Does anyone want to know how?

Today's post, in which I argue with Peter Coffee

Peter Coffee is waxing strongly on the benefits of agile development at:

http://www.eweek.com/article2/0,1895,1993420,00.asp?kc=EWITAEMNL072406EOAD

I know I am sounding like a broken record, but he asked for feedback by email, so this what I sent:


"As every good electrical engineer knows, the longer the signal path, the greater the parasitic losses due to inductance."…
An analogy that just rolls of the tongue… and has no relevance at all to the topic. Let's try another one: when I have my dream house built some day, I want to deal with the architect and maybe the overall contractor, I do not want to talk to the carpenters/bricklayers/plumbers/etc.

Business people do not want to invest time in software projects if they have to deal with the programmers; their respective frames of reference are so different they cannot communicate effectively.

That’s when a System/Business Analyst is needed, to get the business needs and develop the blue prints for the system. S/B Analysts speak both languages, and are the interpreter between the business and the programmer.

Why does agile have to react so well to change? Because the programmers did not hear what the business wanted in the first place, so odds are the software will be wrong. The SOFTWARE has to change because it is wrong, not because the business changed.

Oh, and please give the word "Agile" back to the English language; agility is not restricted to one methodology. Call yours "Programmer-Driven Development", no one can argue with that name.

David Wright

Comments, anyone?

Business Analysis / Architecture "Quote of the Day", 20/07/2006

"Today, with the Zachman Framework as a foundation...we now know that if two people discussing a prospective system cannot understand each other, it is probably because each is operating in a different cell of the framework. Neither professional is necessarily incorrect or incomplete, but simply viewing the same problem space from a different perspective"

... Barbara van Halle, from her Foreword to 'REQUIREMENTS ANALYSIS: From Business Views to Architecture' by David C. Hay (Prentice-Hall, 2002)

That book on Requirements Analysis was just delivered...

"Requirements Analysis: From Business Views to Architecture" by David C. Hay.

I have just finished the Forwards and Introduction, and I believe Mr. Hay may have already written the book I have thought about writing myself (assuming one can actually write a book just because you want to...).

I could wax on about specific quotes and lines of interest, but the Introduction is excerpted in full at amazon.com ("Look Inside The Book"), along with the Table of Contents, so I recommend all Business Analysts go to Amazon and read it... and then I am sure you will want to buy the book.

http://www.amazon.com/gp/product/0130282286/ref=si3_rdr_bb_product/104-5814185-0628700?ie=UTF8

Why is this a book I wish I had written? It is not a sales pitch for any one methodology, it is the sum experience of a working Business Analys/Consultant who has seen ALL the methods and models out there, now and in the past, and has taken Zachman's Framework and populated all the row 2 and 3 cells with all the Artifacts one might use; and then he sweeps across the columns speaking to all the artifacts and how you might use them. He emphasizes that the Data and Activity columns have the most artifacts, because that is where most of the analysis work has been done over the last 30 years; but he then states he is going to keeping moving to the right to those columns where not many have gone before, all the way to Motivation, and mentions some artifacts that will be unfamiliar to most people ("filters", "attenuators?").

So, on to Chapter One: "A Framework for Architecture"...

Business Architecture?

My past experience has included stints as an 'Architect', rather than 'Analyst', and one of those titles was truly involved in Architecture, with a focus on Models and the Zachman Framework.

That was a few years ago, but I was recently asked for my views on what "Business Architecture" is, and here is what I wrote:

Three key aspects of Architecture:
1) It is not an end in itself; Architecture exists because things need to be built.
2) Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
3) Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

The most common and oldest form of architecture is construction of buildings: dwellings, work-places, etc.. The need for Architecture arose centuries ago when construction failed or the end result collapsed. All of the above three aspects are inherent in this field: the known and desired end product, defining and integrating all components needed, and the layering: from a high-level floor plan, to blueprints, to wiring diagrams and other detailed specifications.

A Business, any Business, has the same need for Architecture, and presents further challenges than constructing a building. Buildings are complicated, being made up of many pieces that have to fit together, but they are finite; you can count and describe all the pieces which will be in place when the building is complete. A Business, and really Enterprises of any kind, are complex, meaning that they change over time; pieces may be re-arranged to fit together in a different way (e.g. org chart re-organizations or process improvements), and some pieces may be revamped or enhanced (like Information Systems), while other pieces are retired/discarded and new pieces added to the Enterprise (like Equipment).

In the end, the most commonly identified pieces of an Enterprise are its resources (people, capital, raw material) and the systems/processes that use the resources to produce an end product or service. Enterprises use many different kinds of systems in their operations, many of which are highly cohesive and de-coupled (their relationships to other pieces are few and well-defined), e.g. different assembly lines of a manufacturing company.

On the other hand, Information Systems used by an Enterprise in support of its operations increasingly need to be aware of the full scope of the Business, across all resources and processes. This presents its own Architectural requirements, such that a complete, all-encompassing Enterprise Architecture for Information Systems is needed, if systems and technologies (the “pieces” of the Information Systems) are to built/acquired, deployed and used effectively, without the redundancy, duplication and inconsistency of information systems delivered in the past.

Architecture within a discipline comes to depend on common practices and standards over time to increase efficiency and eliminate unnecessary re-invention; it is commonly stated that Information Systems delivery as a discipline is still too young to have developed such commonality, but work has begun, notably by John Zachman and his and his Enterprise Architecture Framework of the late 1980’s.

See http://www.zifa.com/ .

Here are your Resources (the columns) and your layered views (the rows) that will take a Business from its highest-level context through to functioning Information Systems.

They key row to me is Row 2, the Business Model. Row 1 provides, as its says context/scope. It is very important to understand the scope/boundary of the Enterprise for which the architecture is being created, especially when large Businesses define themselves as being constituted of multiple ‘Enterprises’. Once that is defined, which should not take very long, the critical development of the Row 2 Business Models can proceed; these must accurately represent the in-scope enterprise/business at a detail level, otherwise the remaining lower rows (where most of the money is spent) will not lead to building the right Information Systems for the Business.

Finally, Zachman always states that he has defined a Framework, not a methodology to populate the cells, or define what types of models should be used. Given the framework, different methods/models can be used for creating (and communicating!) an Enterprise Architecture for a Business, often with a focus on accelerated or prioritized delivery; most owe some debt to the original Information Engineering developed by Finklestein in the 70’s and popularized by Martin in the 80’s. The key point here (and the last one in this dissertation) is that it does not matter which methodology you use, as long as you pick one and use it for all it is worth, both to create systems, and as a language common to all participants in the Systems Delivery Process (SDP).