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?
Thursday, May 03, 2012
Wednesday, March 28, 2012
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.
Friday, March 09, 2012
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 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?
Thursday, January 05, 2012
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.
Wednesday, March 23, 2011
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.
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.
Wednesday, March 09, 2011
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
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
Wednesday, March 02, 2011
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
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
Friday, February 25, 2011
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
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
Wednesday, February 23, 2011
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.
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.
Thursday, December 30, 2010
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
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
Wednesday, December 29, 2010
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....
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....
Wednesday, December 22, 2010
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?
Tuesday, December 21, 2010
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?
Friday, June 25, 2010
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.
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.
Thursday, June 10, 2010
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.
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.
Saturday, May 29, 2010
Another attempt to understand Business Analysts
I am sure Ann Hall over at itbusinessedge.com is a nice person, and I appreciate her interest in what Business Analysts are or do, but she is not helping by quoting people who say my real key skill is customer service... have a look at http://www.itbusinessedge.com/cm/blogs/all/does-a-business-analysts-background-matter/?cs=41432#cf
Thursday, May 27, 2010
Conversations
Linked In is a pretty good place for conversations these days, here is one on "Should the BA be a SME?" at http://bit.ly/9VhruQ (No fair guessing my view before reading it...)
Thursday, May 20, 2010
Blogger's Block
I seem to be posting less often these days. and if no one else has coined the term, I will call it "Blogger's Block."
I have said before that when blogging first appeared, I paid it no mind as it seemed that they were all (mostly young) people's public diaries; eventually I saw that there were more and more blogs that were about topics of interest, the main ones for me being work-related on business analysis and methodologies and such. One of these must have been on blogger.com, which basically said I could have a blog too, just sign up...so I did. This was about the same time that after attending BA and IT conferences for many years, I realized I had things to say that were just as meaningful as the speakers whose sessions I was attending.
So, the dam was busted, and looking back, I am a bit amazed at just how much I wanted to communicate to anyone who might stumble upon this site. Often it was things I wanted to say in my work environment, but couldn't because my boss would not have liked it or it would have just fallen on deaf ears.
So over 20 years of thoughts and experiences just came pouring out, but the well is drying up. Perhaps it may be that what I am doing now as a consultant lets me speak more freely, along with the fact that I really like what I do now.
So, what to do about this? anything? does it matter? Should I start the "Best of David Wright's Business Analysis Blog", essentially re-run old posts that might still be relevant? or just let it fade away, it's purpose having been served? Stay tuned, anything could happen...
I have said before that when blogging first appeared, I paid it no mind as it seemed that they were all (mostly young) people's public diaries; eventually I saw that there were more and more blogs that were about topics of interest, the main ones for me being work-related on business analysis and methodologies and such. One of these must have been on blogger.com, which basically said I could have a blog too, just sign up...so I did. This was about the same time that after attending BA and IT conferences for many years, I realized I had things to say that were just as meaningful as the speakers whose sessions I was attending.
So, the dam was busted, and looking back, I am a bit amazed at just how much I wanted to communicate to anyone who might stumble upon this site. Often it was things I wanted to say in my work environment, but couldn't because my boss would not have liked it or it would have just fallen on deaf ears.
So over 20 years of thoughts and experiences just came pouring out, but the well is drying up. Perhaps it may be that what I am doing now as a consultant lets me speak more freely, along with the fact that I really like what I do now.
So, what to do about this? anything? does it matter? Should I start the "Best of David Wright's Business Analysis Blog", essentially re-run old posts that might still be relevant? or just let it fade away, it's purpose having been served? Stay tuned, anything could happen...
Saturday, April 24, 2010
Agile is Fragile
Recent experience at a client showed me that Agile can be successful for a project, but maintaining a level of success across projects and organizations is difficult.The client had one team using Scrum that was delivering sucessfully, but several others that were not.
A manager of one of these other teams told me that their biggest problem was turnover in the Product Owner role; a business person would take on the role, get better and betterat it, then change jobs. The team would have to acquire a new person and start from scratch again.
The other most common problems were scope creep, and excessive change during dev sprints in a project. To me, these are another sign that the Product Owner role was not being performed well. Overall, the discipline needed to make Scrum effective was not being practiced.
The client's response to these problems was to focus on a process for requirements definition, to have stable and clear requirements available for use by a dev team, irrespective of the development process that team may use. Yes, this can be seen as a step backward from an Agile point of view, but what else could the client do?
As a consultant involved in implementing the new requirements process, I have to acknowledge that some readers would say I am biased against Agile/Scrum. What I am biased against is any process that is not working. The client's original use of Scrum is certainly before my time, but it can be safe to assume that it was done for good reasons, one of them likely being that up-front requirements was not working for them.
Over time, the above agile fragilities became apparent and something needed to be done. Rather than try to improve their use of Scrum, the client looked back to its original problems and determined that ifScrum did not solve their requirements problems, what else might? ...leading to me coming to this client to do a Requirements Process Improvement program.
That does leave the one team that is successful with Scrum; how can a Requirements Process fit into what they do? What their team leader and I have worked out together is that functional requirement statements (e.g. The system must have the ability to create an Order) can be matched to User Stories. A good set of Requirements helps deffne a much better and stable Product Backlog to use going forward with Scrum.
In the end, it is about the process, whatever it is, that works for an organization, delivers successful results, is repeatable, and can be learned by others with the same results; anything else causes more problems than it solves.
A manager of one of these other teams told me that their biggest problem was turnover in the Product Owner role; a business person would take on the role, get better and betterat it, then change jobs. The team would have to acquire a new person and start from scratch again.
The other most common problems were scope creep, and excessive change during dev sprints in a project. To me, these are another sign that the Product Owner role was not being performed well. Overall, the discipline needed to make Scrum effective was not being practiced.
The client's response to these problems was to focus on a process for requirements definition, to have stable and clear requirements available for use by a dev team, irrespective of the development process that team may use. Yes, this can be seen as a step backward from an Agile point of view, but what else could the client do?
As a consultant involved in implementing the new requirements process, I have to acknowledge that some readers would say I am biased against Agile/Scrum. What I am biased against is any process that is not working. The client's original use of Scrum is certainly before my time, but it can be safe to assume that it was done for good reasons, one of them likely being that up-front requirements was not working for them.
Over time, the above agile fragilities became apparent and something needed to be done. Rather than try to improve their use of Scrum, the client looked back to its original problems and determined that ifScrum did not solve their requirements problems, what else might? ...leading to me coming to this client to do a Requirements Process Improvement program.
That does leave the one team that is successful with Scrum; how can a Requirements Process fit into what they do? What their team leader and I have worked out together is that functional requirement statements (e.g. The system must have the ability to create an Order) can be matched to User Stories. A good set of Requirements helps deffne a much better and stable Product Backlog to use going forward with Scrum.
In the end, it is about the process, whatever it is, that works for an organization, delivers successful results, is repeatable, and can be learned by others with the same results; anything else causes more problems than it solves.
Thursday, March 25, 2010
A Year on Twitter
I was a late-comer to twitter, one of the horde that joined in 2009. I was in a similar fashion a late-comer to blogs. When blogging started picking up, it was mostly painted as individuals exposing the equivalent of personal diary entries to the whole world. This was not something I had any interest in, but it eventually became apparent that people were blogging about topics of interest, including business and systems and methods and so on. Many of these people were authors of note on topics of direct interest to me. After seeing some of these, and realizing how easy it was, I started this very blog. It may or may not have have reached an audience of any size or import, but I have enjoyed it as an outlet for my thoughts and opinions on Business Analysis.
Then came Twitter, also first painted as people's random thoughts or status, the famous "what I just had for lunch" type of tweets; as before,this did not interest me. Then at the beginning of 2009, I saw some articles (and probably blog posts!) about how this odd Twitter thing might actually be useful, to busineses for example. I also saw on blogs I read the appearance of "follow me on Twitter" announcements. So I joined and started following some of these people. I have a been long-time user of Google Alerts to find things of interest to me, but I found I was getting links to things from Twitter that Google didn't pick up. It is apparent that following someone because of one interest may lead to other unexpected content. This is what I have found Twitter most useful for. People will tweet when they have a new blog post, and then tweet links to other things of interest.
I then discovered all the Twitter apps that tell you how influential you are and such. One thing they usually consider is if you are engaging with other tweeters in conversations, as opposed to just tweeting your own stuff all the time. I would say that of about the 300 people I follow, I do have conversations with about a dozen or so people, mainly other BAs and Systems folks.
The interesting thing is when you have a (probably one time) conversation with a more famous person. They may be tweet somethinng or even ask a question, which spurs me to reply. Most times the replies are not returned, but once in a while they are, which is oddly gratifying; recent folks I have conversed with are comedienne Elayne Boosler, and Peter Travers, movie critic at Rolling Stone. Why does this seem special? I guess it is like getting 15 seconds of fame (a whole 15 minutes of fame being so 20th century).
After a year, I guess what may be most surprising to me is that I have acquired over 500 followers... I mean, I think I have some interesting or funny things to say on occasion, and I do my share of re-tweeting, and I do tweet when I posted on this blog, or over at ITWorld Canada. Yet it does astound me that this has led to me to slowly but surely getting more and more followers. I don't expect I will ever have thousands and thousands, but actually getting into the hundreds was something I wasn't expecting a year ago.
Sure, I have used various apps to analyze who is following me. It is true that many are automated follows, like when I tweeted about the Toronto Blue Jays one day, their twitter account started following me. Then their is always the occasional email about a new follower who turns out to have been suspended for "suspicious activity". But there are some people following me I just don't understand, like all those people who describe themselves as on-line marketing experts.
However, there remains a group of people that number in the hundreds who found me somehow and decided "yeah, I will follow this guy." So, if you fair reader are one of those people, thanks a lot.
Then came Twitter, also first painted as people's random thoughts or status, the famous "what I just had for lunch" type of tweets; as before,this did not interest me. Then at the beginning of 2009, I saw some articles (and probably blog posts!) about how this odd Twitter thing might actually be useful, to busineses for example. I also saw on blogs I read the appearance of "follow me on Twitter" announcements. So I joined and started following some of these people. I have a been long-time user of Google Alerts to find things of interest to me, but I found I was getting links to things from Twitter that Google didn't pick up. It is apparent that following someone because of one interest may lead to other unexpected content. This is what I have found Twitter most useful for. People will tweet when they have a new blog post, and then tweet links to other things of interest.
I then discovered all the Twitter apps that tell you how influential you are and such. One thing they usually consider is if you are engaging with other tweeters in conversations, as opposed to just tweeting your own stuff all the time. I would say that of about the 300 people I follow, I do have conversations with about a dozen or so people, mainly other BAs and Systems folks.
The interesting thing is when you have a (probably one time) conversation with a more famous person. They may be tweet somethinng or even ask a question, which spurs me to reply. Most times the replies are not returned, but once in a while they are, which is oddly gratifying; recent folks I have conversed with are comedienne Elayne Boosler, and Peter Travers, movie critic at Rolling Stone. Why does this seem special? I guess it is like getting 15 seconds of fame (a whole 15 minutes of fame being so 20th century).
After a year, I guess what may be most surprising to me is that I have acquired over 500 followers... I mean, I think I have some interesting or funny things to say on occasion, and I do my share of re-tweeting, and I do tweet when I posted on this blog, or over at ITWorld Canada. Yet it does astound me that this has led to me to slowly but surely getting more and more followers. I don't expect I will ever have thousands and thousands, but actually getting into the hundreds was something I wasn't expecting a year ago.
Sure, I have used various apps to analyze who is following me. It is true that many are automated follows, like when I tweeted about the Toronto Blue Jays one day, their twitter account started following me. Then their is always the occasional email about a new follower who turns out to have been suspended for "suspicious activity". But there are some people following me I just don't understand, like all those people who describe themselves as on-line marketing experts.
However, there remains a group of people that number in the hundreds who found me somehow and decided "yeah, I will follow this guy." So, if you fair reader are one of those people, thanks a lot.
Subscribe to:
Posts (Atom)