In response to "#NoEstimates Part 1: Doing Scrum without estimates"

In response to "#NoEstimates Part 1: Doing Scrum without estimates" at http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/

Sure, estimates are, well, estimated... based on what the person estimating knows at a point in time, the choices are (1) I estimate it it will require "X" to do it, or (2) I can't estimate what is required to do it. I think this comes down to people not wanting to accept that an estimate could be wrong, or not right enough.

I get an estimate when I need car repairs, to make sure I can or want to afford it. My mechanic calls me when he finds something he did't know that will change the estimate, and I decide what to do. If I find over time that my mechanic always under-estimates the cost, eventually I will change mechanics. The average reality should be a bell curve around an estimated value, an estimate is almost never exact, but a statistically acceptable variation is what you should look for.

   Now, such analogies of physical things are problematic when used to describe an aspect of software development. Software is intangible for one thing, and we really haven't been creating it very long to have some good tools like other disciplines (like Engineering) for predicting outcomes; but like everything else, it takes time and money to create it, so the people investing that time and money usually want an idea of how much that investment will be to get what they need. Just saying an estimate is worthless isn't really going to go over well.

    The advantage of software over physical things is that you can indeed create small amounts of it that can be seen to work. Long before 'agile' got its name, a lot of software projects switched from estimates  to time-boxing: give me x amount of resources and the project will deliver what it can in that 'box'. Investor spends a little to see what he can get for that amount. If it looks good, run another time-box. If it doesn't look good, you can stop with only a small investment amount having been spent.

    Lastly I would comment on your statement on what does an estimate have to do with creating good software and a good return on investment. ROI is a funny thing, often very date-specific; delivering great software after a competitor has already done it and captured the market will kill your ROI. Some windows of opportunity are very short; miss them and the return is nil. In these cases, you have to have some way of knowing if you can make the window. Like it or not, an estimate is one way of trying to figure that out. It is these  kinds of situations that will make investors wary of new development and look for packages or services to meet the need. Nothing is perfect  but not being to estimate software development may just lead to no new software being developed.

Business Analysis - what is it, anyway?

Way back in college I had a an economics professor who was a bit radical. I took his Intro to Economics course, and the first thing he said is " The only thing I am not allowed to change is the name of the course, but  what I will be teaching is totally different than what the course description says." And that is what he did.

I say that because sometime between then and now I started this blog and called it "Business Analysis". At the time it seemed to be the best name for attracting readers for what I would write.

Since then, one of the ongoing discussions out here in the interweb is, just what is Business Analysis? What does someone called a Business Analyst do? My usual rejoinder is to re-use of some Bill Clinton's words: "It's the Requirements...dummy." OK, I leave out the "dummy" unless i really know who I am talking to, but that is the essence. Suffice it to say, my answer (repeated many times, which you could see across many linkedin BA groups) has not  settled the issue. And that's OK, one must not assume their opinion will matter to everyone, especially when they have not paid for it (like buying a book or attending a conference).

(An aside: I was in a tourist shop somewhere and it had a little laminated sign that said "Everyone is entitled to my opinion." I bought and put it on the wall in my cubicle... when I still had one.)

So, to get to a point here, I wish I could change the name of this blog to something more specific to Requirements, but so far I find that is not possible on this platform, and I don't want to start a new one and lose followers and such. That is a technical problem, but it illustrates that I want to be more specific about what I post about. I think that could be summarized with a title like "Requirements Discovery". Until I (bother to) sort out the tech thing, just think of that name when you come by this blog.

So, if you are reading this post because of it's title, I will admit that I did not specifically answer the question; I can only opine on what I think it is: that its core is Requirements Discovery, Description, and Documentation and, despite what else a Business Analyst is asked to do (project manage, test, etc), BAs are the only people/role that has this focus.I don't mean to restrict the scope of what anyone thinks Business Analysis is, but I say if you are not doing Requirements work, then you are probably doing something other than Business Analysis.

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

Follow-up to “So, you’re buying a package? Don’tforget your business requirements…” Don’t over-analyze!

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement  statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs,  so you can best evaluate those packages. 

“Why do I need Requirements? I’m buying a Package!”

In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.

However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it.  It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.

When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn't see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place.

This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster.

It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements.

A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”.

(see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).

Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management "failing to timely and accurately define its business requirements" as a contributing reason for the failure.  

(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments).

(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see  http://www.iag.biz/resources/library/business-analysis-benchmark.html  )

So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.

 

When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through.

This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements.

And last  but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.

These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.

If by chance and very good luck, the project has reached this without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.

So, you’re buying a package? Don’t forget your business requirements…

documented Requirements as an essential artefact for systems development

Let’s start with a clear statement:  I view documented Requirements as an essential artefact for systems development.

Given that, I don't want to imply that Requirements are 'sacred' in some way or worse yet, an end in them-selves. They are a vital but intermediate deliverable along the way to delivering the solution that your business needs to succeed.

This brings me to the often-cited problem in Requirements work most commonly known as 'analysis paralysis'. Requirements gathering, analysis, and documentation cannot be some endless task that defers delivering the Requirements because of uncertainties or changes in the details of the Requirements. It does require sufficient time, but historically I have seen the effort spent on Requirements average around 25% of a total systems project. If you are spending more than 25% on a regular basis, you might have some paralysis going on.

(Sidebar: the other 75%? Typically I see 50% on design, build, and unit testing, and 25% on the rest of Testing: System, User, Acceptance, Volume, Regression, and probably more I am forgetting.)

How can you avoid paralysis?
- Define a clear scope of the Business process or function that is to be supported by the solution. If you have or can quickly put together a process map (start by defining all the external events the business must respond to), then it can be shown what you are gathering Requirements for, and what you are not. Having that Process Map also helps identify units of work in process steps that can be documented as Use Cases.
- If nailing scope down is difficult, then time-box the work; take what you do have defined as likely in scope, and spend 2 to 3 weeks of focussed work with business involvement, and you will be surprised the volume of Requirements you will produce. Stop at the end of the time-box, and re-group/review with your Sponsor. You may have enough to start a round of development/delivery, or a better view of how much time you need to finish a complete set of Requirements.

It is also important to recognize the Requirements will change, but not necessarily for the reasons you might think. For example, you may document a portion of the requirements and review it with the business staff involved in the gathering, and you just may have written it down wrong or misunderstood what they told you; reviews/walkthroughs are essential for any quality product. If you can succeed in getting agreement that the documented Requirements are correct from the business, the amount of change after that point will be minimal.

Agile methods proponents will tell you the business changes too much and too often for documented requirements to remain valid; don't believe it. Core information systems requirements about collecting, storing and using data do not change much over time; what does change the most is process/procedural activities, the main reason why an Information System should not automate business process, especially now that BPM tools are available that are designed to accommodate procedure changes. As author Steve McConnell once said, the main reasons requirements change during agile development is that the requirements were not fully investigated before development started.

The last advice I would offer to fellow BA's is that you do document the Requirements as your work, but you do not own them; they belong to the business. So, don't agonize over what may happen to Requirements after you have delivered them. There is a quote about working whose source I must track down, as it guides me every day; it is:…

"Show up on time, do your best; don't get attached to the results".

Wise words. Besides, there is always another project up next that needs its Requirements documented, so get to it!… 

Writer's Block

I have this current desire to write something meaningful about business analysis, and information systems in general, but the spark of a topic eludes me. I have been prowling aroung the various LinkedIn groups, then over to Modern Analyst, and then to BA Times... leaving the occasional comment on somebody else's post, but even other peoples' posts seem to be covering mostly the same ground: BA social skills, ruminations on agile, etc.

Other things I have grown tired of include programming as an art (it isn't), and the mis-use of the terms "iterative" and "incremental"... maybe I am just getting old...

I remind myself that I am always looking for more about the confluence of business process managent, business rules management and data services, but don't see much. The vendors are getting there, IBM of course, and a search finds offerings from SAP and Bosch, but I don't get the sense that anyone is actually doing it.... or, they are and keeping it quiet, since the potential for improvement can greatly increase competiveness.

Anyone have any tales to tell about this?

Software Engineers? real ones?

Anyone who attended an Engineering School for Software Engineering, I would like to hear about your experiences and the merit of what you learned. I often like to propose to people that software development should be following an engineering approach, as opposed to craftsmanship or "artistry', but I am not an engineer, I took Comp Sci in University (a long, long time ago, in what now feels like a different universe).

So, please use the comments section for this post to educate me on real Software Engineering, it will be greatly appreciated.

Are we past the period of "Agile vs. Traditional"arguments?

Are we past the period of "Agile vs. Traditional"arguments?

Using Twitter and various industry newsletters, I try to keep up on the state of systems delivery methodologies and techniques (or whatever noun you like to describe these things). For a long time in the first decade of this century, you could hardly go a day without someone weighing in on the "Agile vs. Traditional"topic; in the early days, it got quite emotional and vitriolic at times. The debates and discussions got more civilized over time, and now I see little or no debate.

So, did Agile "win"? Or has it been absorbed into some new overall way of doing things? I still see many articles on Agile, but they seem to be more on how to make it work rather than why you should use it.

Let me propose this "new way" as follows: we need to move our focus from agile systems development to developing agile systems. Thoughts?

Using requirements tool remotely.

I have just realized that my last post here was back in May of last year... probably due to a combination of being busy with work I am enjoying, and not having any sudden urges to share something on the overall topic of business analysis, or IT in general.

So what's keeping me busy? an on-going project for a new system that has multiple stakeholders spread across the United States. What this means is that the project is using a requirements tool accessible over the net, so we have a meeting or two with stakeholders gathered in one place, followed by follow-up work done remotely using the tool, email and skype. That meant a lot less travel, and my "commute" was to walk down the upstairs hall in my house.

The interesting thing is the remote use of the tool. Maybe only a few years ago, being able to do this would have been seen as an amazing new capability; now we get annoyed if response time is less than immediate. It would seem that user expectations are still zooming ahead of tech capability.

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 a spreadsheet expert 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 cost and benefit dollar values, 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; it’s not enough that a project makes money, 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.

And that's it for now, comments welcome.

Defining the benefits of an IT project is a different issue from defining costs;

...continuing from the previous post...

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. However, benefits 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 it could lead 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 (taking orders on-line saves on paper costs...whoopee!), or, projects that are expected to increase revenue/income.

The question becomes: how much will such a 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.

Next time: Cost - Benefit Analysis

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

what projects does the Enterprise consider to be most valuable?

...continuing from the previous post...

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 often 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

Lets’ start with Costs (it’s easier than Benefits, at least); essentially you need to define what resources, services and purchases will be needed when executing a project.

IT 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.

My experience with estimating has led to always determining how 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 supports 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).

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.

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) you 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.

That's Costs... next time : Benefits

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

Who"owns" IT Projects?

Who “owns” IT Projects?

I said I would post on this topic, but it is really more of a history piece. Here is an excerpt from my book “Cascade”:

CHAPTER FOUR– Pick the Right Projects for the Business
…
Early computer projects 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); and how did they all get started anyway?

(… because the business looks around and sees) a lot of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.

(This has to change to get these projects under control, including a new awareness…)

That awareness should include:

1) A recognition that IT projects do not belong to IT, they belong to the Enterprise as a whole, even if various non-IT parts of the Enterprise are assigned responsibility for some sub-set of projects.

2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the Enterprise’s Strategic Plan.

3) The realization that dozens or more project ideas may be in play at any one time, but the average Enterprise does not have the resources to do them all; it must pick from the candidates which projects will get to proceed, and it must continue to do this as current projects are completed and resources are freed up.

It all boils down to best use of limited resources. The term that has emerged to describe all 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 (commonly called Construction). 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 as described above. 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 Enterprise.

The key question then is: what projects does the Enterprise consider to be most valuable? (That’s for next time.)

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

Maybe it is time to define "customer" in IT Projects

IT projects and methods seem to big on the word "customer" these days...

Common definitions of:

customer - one that purchases a commodity or service

purchases - the acquisition of something for payment

So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.

I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.

Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.

However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.

So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.

But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.

IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.

BPM: It’s About Managing Change (Fourth in a Series) - Rules, Rules, Everywhere Rules....

So, from even the list of examples in my previous post, it would appear that rules are everywhere in a business, and this is in fact a testament to the value of managing business rules effectively. For the most part, though, they can be categorized in relation to how they impact the other two main components of information systems: data and process.

For your data needs, business rules help with conditional relationships and data values. Consider the example of when an order qualifies for a discount. When an information system is used to create a new order, the database schema would have informed the programmer that certain data attributes are needed to create a complete and correct order — like item and discount — and what values those data attributes are allowed to be for the order to be considered valid for the business. However, a database schema cannot document and enforce rules about values of a field that are dependent on the values of other fields; those are rules. Further, if an order needs to have an association with a credit authorization when payment is by credit card, that is a conditional data relationship that cannot be described in a database schema; it is a rule.

For your process needs, business rules are critical for the decisions made in a process. Basic implementations of a BPMS will automate the flow of activities but will stop executing and exit to a user prompt when it reaches a decision point, the diamond in the diagram. A person needs to respond to the prompt and indicate which path the process should follow next. This is better than not having a BPMS, but it is not yet an ideal implementation.

Why? Consider that most decisions made in a business are consistent and ongoing applications of rules (e.g., does the customer qualify for a discount on this order?) and are made many, many times a day. In these situations, the person is looking up the rules in a manual or, worse, applying them from memory, which we all know can be faulty in even the best people. This is where BRM has its biggest impact. It can elicit those common rules out of the manuals and memories and get them into a BRMS, and then business processes will flow uninterrupted until a new situation arises. That is when a person is really needed, and once the new situation is understood, it too can be defined as a rule and added to the BRMS.

Next Time: A Model for Business Operations - Process , Data and Rules

BPM: It’s About Managing Change (Third in a Series) -Supporting Business Rules; will Brute Force work?

"....systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially."
 
Many organizations tried to solve this problem with brute force: adding more resources, running more projects, outsourcing what could not be done internally. Other (fewer) organizations saw the diminishing returns that approach produced and started evaluating the problem laterally. They determined that data definition and then process definition captured a lot of what business is about, and automating their management was of benefit, but neither included "the set of rules that determine how a business operates — that is, rules that prevent, cause, or suggest things to happen." ("Defining Business Rules — What Are They Really? Final Report, Revision 1.3." Business Rules Group, July 2000)

These organizations realized that just as data needed a DBMS, and process needed a BPMS, business rules need business rules management (BRM) and a system to support it: a BRMS. I’m not talking about codelike procedures; these are human-readable rules that can also be implemented as declarative statements, such as:

- A customer can place an order, only if they are 18 years or older.
-A customer can place an order on credit, only if their credit rating is "good" or "excellent."
-The insurance coverage for a 10-year term life insurance policy must be $50,000 or higher.
- Premiums paid by direct debit must have a monthly payment frequency.
- A credit application greater than $1,000,000 must be approved by the manager of underwriting.
-An order is fulfilled, only if the ordered items are in stock.

As declarative statements, business rules need to be automated irrespective of any procedural order. All rules are applicable to the business at any time, not according to any order specified in a coded program. The structure of the rule statements must meet the two primary needs: readability and execution. The means of accomplishing this, fortunately, have already been developed and standardized for us through the OMG and its "Semantics of Business Vocabulary and BusinessRules (SBVR), Version 1.0.". The above examples meet the requirements of this standard and would be executable by any BRMS that supports it; so now your rules are don't have to be frozen in code.

Next time: Rules, Rules, Everywhere Rules....

BPM: It’s About Managing Change (Second in a Series) - Things change, but are they really different?

We can agree that business processes change a lot, but a little analysis of the nature of these changes reveals that they are of the same type(s): activities are added or removed, or the order of the activities is rearranged, or the criteria used to make decisions changes. This is what business process management systems (BPMSs) were created for: defining activities, decisions, and their order in a business process, with the ability to change the process in common ways without requiring an IT project. The power of a BPMS stems from identifying these stable patterns of change and supporting them with structures — activities, decisions, and the definition of their order — that allow for change.

THE DATABASE ANALOGY

To illustrate the point of stable change, consider database management systems (DBMSs) as an analogy. A database embodies a model/structure of an organization’s ongoing data needs, patterns of entities/objects, and their relationships — what database analysts know as the "schema." With this stable structure, new occurrences of data are added as needed through application systems; the need to add new data item definitions to a database is very infrequent, occurring only if the business of the organization changes significantly or the organization enters a new business.

Further, databases are not just containers; they are rule enforcers.The optionality and cardinality defined for relationships are rules, such as "an order must have at least one item being ordered but can have many items being ordered as well." This is what any business person will tell you is true about an order, so a database can be used to enforce these rules.

This enforcement is good, but it is also limited. Database rules, especially optionality, are cut and dried; they cannot implement conditional situations, such as "a relationship is mandatory only when x=y." For example, an order must be related to a credit approval if the payment method is credit card. When the business presented this kind of situation to IT, the data edit was born. As you might expect by this point, this response was implemented in code and used primarily when a new occurrence of something, such as an order, is created by an application system. It has also been known as the input edit, the screen edit, and the field edit. A special case is the cross-edit, where the value of one data attribute is constrained by the values of another. For example, a discount for an order can be greater than 25% only if a certain type of item is ordered.

This solution using code has caused even more problems than the examples described previously, because "data edits" are a technical IT term for business rules, and what I have learned is that business rules change even more often than the business processes that use them for guidance. Working in insurance, and then lending, I have often seen code that implemented underwriting business rules to automate decision making, only to then see the business rules change enough that the results produced by the code were no longer valid and had to be extended by manual workarounds. So the systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially.

Next Time: Supporting Business Rules; will Brute Force work?

BPM: It's About Managing Change (First in a Series) - Why are Business Processes frozen?

Despite many things written and said about businessprocess management (BPM), it is really one thing for certain: an automation improvement that supports change management.

WHY ARE BUSINESS PROCESSES FROZEN?

Business processes are the lifeblood of an enterprise, moving and shifting to respond to the ever-changing business environment. They are sets of activities in an organization that are performed in response to a trigger— an external stimulus, an internal state change, a point in time that has been reached — to provide a desired result in response to that trigger.

The nature of business processes lends itself to diagramming them in some manner. You can present the starting and end points as circles, all the activities as boxes, decision points as diamond shapes, with arrowed lines connecting all of the above (swim lanes optional). What all this drawing means is that, given sufficient effort, it is possible to fully define a process as it exists at a point in time.

Why the emphasis on a point in time? Consider how most businesses’ processes and activities were automated for the first time: the process was defined, and programmers designed and coded programs for a system that executes the activities. On the day the system is implemented, and for some period of time afterward, it does what it was designed to do, and the business performs its processes using that system. No one is aware that the business process is now frozen in time.

Fairly soon, however, the business decides to change its process somewhat to deal with new problems or opportunities. The system does not support this changed process, so a project is needed to open the system, make the changes (correctly), test the changes, and implement the new programs for the system. This takes time. The business process essentially must be thawed out, redirected, and then refrozen.

By the time this effort is completed, however, the business has more changes lined up. Here we see the arrival of the two curses of information systems: (1) the backlog, and (2) the workaround.

Next time: Things change, but are they really different?

I am ranting about Agile again...

...and I am not proud of myself. A couple of years ago I worked myself to a space where if it worked for you, what ever method you liked, my feeling was "power to you". Even among Agile proponents there were some reasonable voices who decried the prevailing "If it isn't Agile, it's Crap!" hysteria.

But I obviously keep tuned to writings and postings about Business Analysis and Requirements, and some of the stuff that used to annoy me is seeping back into the mainstream, basically that "we have to do all this hard Agile stuff because you can never get good requirements before you start coding."

A lot of it is couched in seemingly sincere attempts to find a place in Agile, in Scrum particularly, for that poor soul, the Business Analyst. Even actually sincere attempts to do this carry the implied the subtext that "we have to find something for the BA to do, because he could never manage to do what he was supposed to do, get the requirements done first.... we would not want to see him/her lose their job..." So, let's make him the Product Manager, especially since the real business product manager can't be bothered to get involved. (Corollary note: i see all the time that developers want to work more directly with business users, but I can't say as I see business users saying the same thing about developers.)

So, I try ignore this and carry on, but then I end up commenting on posts like
http://www.batimes.com/articles/the-business-analyst-facilitator-role-in-an-agile-software-development-team.html

Maybe things will calm down again and some moderation will prevail... I hope so.

Cutter IT Journal: my article on BPM

Hi all,

Have a look at http://www.cutter.com/offers/bpmalternative.html to see the May issue of the Cutter IT Journal, with my article on BPM leading off.