Agile Organizations - Dealing with Expected Change

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is external. When the surroundings that generate change are actually controllable, then the need for agility is greatly reduced. Agility comes at a price, and maintaining agility is a waste of resources when change is controllable.

A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise.

Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion.

The basis for controlled agility in an enterprise includes understanding that:

•         an enterprise runs on its processes, not its org chart
•        processes are composed of distinct activities and decisions
•        processes run on information, gathered and stored and used
•       processes are guided by business rules, especially when decisions need to be made.

With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change.

Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change.

Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project.

A major use of rules is to support making decisions.  Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules.

What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile.

Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations.

Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility. 

To Agile or Not To Agile

After a long period of trying to grapple with "agile" or "not agile" etc., I finally realized something; it really depends on what you are trying to develop. My thoughts now divide software grossly between "product" and "process".

If you are developing a software product, especially to actually sell to customers, then I think product development methods are the way to go, and Agile fits this approach well. You do start with a Product Owner's vision of functionality, and user stories are a great way to express that vision as a starting point for developing a prototype or first release.

If you are dealing with a business process to automate, then a 'vision' is not appropriate; you have to document what the process is, completely and clearly. High-level process maps supported by use cases are a great approach for this. You have to  realize that there can be no arbitrary first release for a process based on a sprint or other cut-off. If you are automating a process to, say, transfer money from one bank account to another, you can't first release the "from" account piece without the "to" account piece.

So, use the appropriate technique for the software you are developing; no one technique meets all needs.

You have to have an acceptable budget for a project before you can start managing the budget for a project.

Over the decades, I have seen many methods and tools for managing things you create, but don’t offer any help in actually creating them. In the BA/requirements world, the key example is Requirements Management Tools; useful once you have requirements, but defining clear and complete requirements is the difficult part. Anyone who has read my past posts knows that doing requirements definition/discovery is, well, what I do.

But there other such things, and some of which having good requirements can help. For example, do you need to budget for your projects before you start them? You have an annual or quarterly process about submitting budgets and getting approved, and then a separate process for changing the budget during the projects. However, do these processes and supporting tools actually help you come up with a budget number you are comfortable with? No, so you need something else to help with that and, no surprise, requirements can be that something.

What can clear  requirements help you get? Estimates, for design, development, and testing. But, you ask, are you saying to do all the requirements for your upcoming projects long before they start, to get budget amounts? Yes and no. Requirements can be defined at different levels of detail, you just have to balance the level of detail to the granularity of the estimates needed for budgets.

When you actually start to elicit requirements for a project, the first thing you have to do is scope the requirements analysis work. This scoping will take a half-day to a day to complete. What I am suggesting is to do this scoping work-only for all your planned projects. This scoping will provide the main business activities and information  to be addressed in the project. That is enough detail for t-shirt sizing of each project,  small/medium/large; align this sizing to previous projects  of similar sizes, get the costs of those projects (not always easy but it should be somewhere) and you have numbers that are based on something real. The percentage amount of variations might still be high, 20 to 40% for example, but the numbers are based on something real, not just SWAG or other “best guesses”.

Is a day per project for requirements scoping during budgeting too much to ask to get some real numbers? I think not.

Celebrating a 5 Year Anniversary

I am celebrating of those significant work anniversaries in 2013; I have now been a Requirements Consultant for five years with IAG Consulting. For some decades before 2008 I was an employee of several different organizations as (early on) a programmer and then a Business Analyst. As those years went by, I had begun to wonder if doing business analysis as a consultant was a viable career choice; finding IAG Consulting showed me it could be, and it would be tough to see myself resuming my earlier life as an employee. As a consultant, virtually every work day is meaningful and delivers value to a client; you frankly get the focus and involvement of people when you are a clear cost, more than (sadly) an employee Business Analyst usually gets.

On the other hand, I could probably not be the effective consultant I am today without at least many years of the experience I gained as an employee. One thing as an employee does have is usually the chance to attend conferences; I also participated in industry-level standards efforts at different times. In the end, though, the move to consulting was right for me.

Since then, I have worked on projects for dozens of companies, working with hundreds of good business people to help them effectively and completely define their requirements for processes and systems. I expect to be at it for many years to come, so if you organization is looking for this kind of help, come visit us at http://www.iag.biz/ to see what we (and I) can do for you.

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