28 November 2008

Another book report

I've been catching up on my reading lately and thought I would share a little more of it with you.

Sway: The Irresistible Pull of Irrational Behavior by Ori Brafman and Rom Brafman is a book about how people can be influenced. From college students living up to expectations to military recruits meeting drill instructor expectations and many other applications in between.

This book makes the case that expectations can influence outcomes. Using multiple examples of psychological studies, the authors show how a first impression or a preconceived notion influenced outcome. One of the most striking examples was a group of military recruits going into basic training. Each recruit was randomly assigned a personality profile showing them to be officer material, average, or below average. The profiles were then shared with drill instructors saying that the researchers were tracking the recruits to see how well their profiling tests worked. At the end of basic training, the drill instructors were then asked to fill out a questionnaire on each recruit about how they did during training. When the results were compared to the original profiles, they matched almost exactly. The drill instructors were then told what the study had shown and most of them had trouble believing they had been so completely swayed.

Reading this book will make you more aware of the ways that you are being swayed every day. From marketing campaigns to your co-workers, you are being influenced. Once you are aware of it, it is possible to resist some of the more obvious forms of influence. However, it is also possible for you to put it to good use when working on projects.

To be a good leader, a person must influence those they are trying to lead. To be a good Project Manager or Business Analyst, a person should also be a good leader. The theories in this book can help you to improve your leadership ability and help you build your team into a more effective one. I highly recommend reading this to anyone leading, or even just a part of, a team.

26 November 2008

The Drunkards Walk

Time for a book report.

The Drunkard's Walk by Leonard Mlodinow is a nice complement to Nicholas Taleb's The Black Swan. Where Taleb focuses on the blind spot in most statistics, Mlodinow talks about the randomness that fills those blind spots.

If you are looking for inspiration in identifying risks and assessing their likelihood, this book is an excellent way to get in the right frame of mind for the task. There is a lot of good information on understanding probabilities. I know that for me, understanding the probability and how to calculate it has always been a difficult chore and most books are completely inaccessible to me. This book takes the math and makes it wonderfully readable and, more importantly, easily understandable. His examples using gambling are also fun.

I think this book is a benefit to a project manager when doing risk management, risk assessment and the probability of the occurrence of the risk. For me, it has always been most difficult to objectively assess likelihood of a given risk. This book helped me to better understand how to make that assessment.

25 November 2008

Project World and World Congress of Business Analysts (PW&WCBA)

I have been out of town for the past week attending a conference in Orlando, Fl called Project World and World Congress for Business Analysts (PW&WCBA). This conference was organized by The Institute for International Research and included three separate functions: The 4th Annual PMO Forum, The 2nd Annual Managing the Virtual Workforce Forum, and the 9th Annual IT Portfolio Management Forum.

As both a project manager and a business analyst, this was an excellent conference to attend. I can honestly say this was the first time I have ever attended a conference and actually taken notes in the individual sessions.

While I won't bore you with the nitty-gritty details of everything I saw and heard, I will give you the main messages I got from 4 days of listening to some experts in both fields.

  1. If you are a business analyst and you aren't asking "Why", you aren't doing your job. Multiple sessions I attended hammered this point home. Between sessions about what you need to know and sessions about how to get it and document it, the primary point boiled down to you need to know why something is needed/being done/ etc.

  2. If you are a project manager, you should be using the PMBOK® as a reference, not a recipe. Checking off all the boxes on a list will not guarantee success, and in some cases could prevent it. You need to understand what you are doing and why (there's that why again) so you can adjust your method to deal with problems. If you are so caught up in following the PMBOK® that you can't respond to situations that arise then you should re-evaluate your process.

  3. Communicate, communicate, communicate. If you aren't communicating in some way with your team, you are doomed to fail.


And the last thought I was left with was something that we talk about here regularly and in most every site Craig has linked from here:


Never forget that projects are about people.

24 November 2008

No blogging due to Bad Business Process Design

Regular readers will notice that the blog is quieter than usual at the moment.

There are two reasons for this;

1. I do the blogging at home after hours, and
2. The way the Australian telecommunications industry works.

The industry was deregulated in the late eighties and the first 'challenger' company was started; Optus.

As the nineties progressed more competitors jumped in, mostly as resellers rather than full networked service providers. The historic national carrier was insurmountable in fixed line telephony but the mobile market expanded rapidly and plenty of businesses developed their markets.

A decade on and some things are the same; Telstra, our monolithic (almost) monopolist runs most of network connections to people's houses. And all the resellers plug into their management and billing systems.

So when I tried to switch my account with Dodo they followed a process that resulted in a data error and two months of no phone or internet connection (which I am about half way through.)

And unfortunately there are no real alternatives for us consumers.

I know the problem that has occurred. It isn't with a particular call centre operator, nor is it data issues in the database. And it ain't customer error either.

The problem is the lazy business process that has been developed for Dodo by project managers and business analysts. They copied the dominant model in the industry. It is the same one I saw implemented for Optus' reseller product when I was there.

Essentially one physical property account has to be terminated before a new physical property account can be commenced, introducing a series of finish - start dependencies on a process (that can drag on for 2 months if anything goes wrong.)

I wasn't on the project at Optus but I did share my views with the analysts on it - and was ignored, so any Optus readers that have customer service woes as a result of moving house - my sympathies.

Each of these reseller organisations is guilty of building a process that is simple to implement - it plugs easily into the Telstra interface standards, uses the same concepts and mirrors the internal Telstra process (from years ago.)

Each of these companies has made the mistake of playing into a business model that has been designed by their most powerful competitor.

And it could have been so easy to deliver a vastly improved solution to people moving home. It would have been very easy (relative to the amount of customer inconvenience felt across Australia) to implement a system that allows for two concurrent services to be active for one customer.

There is a lesson here for all of us. We are the consumers of the products and services we create.

Try your best to do good for the customer (and yourself)

Hopefully I'll be back online soon.

17 November 2008

Estimating factors

I was just digging around for info on estimating and was drilling into COCOMOII which is a model used for estimating effort developed by Barry Boehm.  It's worth thr trip over to Wikipedia to at least get the basics.

The headline I'll share here is that the essence of the estimation process covers a number of factors which include the following.

Have you done this before?  The degree of precedence within your orgasnation for simialr work will affect your ability to both estimate and to actually deliver the right solution.

How flexible are your goals and processes?  If this project is THE project that is going to develop a whole bunch of architectural foundation work you are going to cost more than others.  If you are stuck with a heavy and bureacratic process - you are stuck with it and the accompanyting work and cost.

How scalable and robust does your soluton need to be?  Quality = cost.  Look for the payoff curve.

How well does your team work together?  Are there boundary disputes?  Doe poeple like working together?  This stuff matters a lot.

Does this sound sensible to you?

There are other methods and there is the no method method.  Whatever models you use, make sure you have informed yoruself about the options.

14 November 2008

Project management problem diagnosis

Suppose you have a problem.

For example, your tech/solutions team are ready and waiting but there is no clear statement of goals or requirements from the customer. Or maybe some stakeholders are continually interrupting you with short term non-core requests that are important to them, and that you kind of have to address. Or maybe there is a problem with a particular piece of work that nobody (or everybody) is focusing on.

The chances are you are not the first project to face this challenge.

Stop and take a moment to consider: What are they main challenges you face today?

Are they unique, or has someone else already dealt with this issue somewhere before?

I just stumbled across a paper at Alistair Cockburn's website that talks about pattern recognition and project management problems. Maybe you could take a look and see if there is already a known cure for your problem.

6 November 2008

Why it is Important that Software Projects Fail

This week, a special presentation by Dr Anthony Berglas.
(The original post of this article is here. This is reproduced with the author's permission.)

Why it is Important that Software Projects Fail

An essay on computer productivity

Dr Anthony Berglas, February/October 2008
Anthony@Berglas.org (Feedback welcome.)
Copy at will but provide attribution.

Abstract

This paper boldly challenges the long established misconception that the catastrophic failure of expensive software projects is detrimental to society. Historical analysis shows that massive software automation has not increased the real efficiency of bureaucracies such as the Australian Tax Office since the 1950s. Any increase in the efficiency of individual workers has simply been consumed by increased bureaucratic complexity, as predicted by Parkinson's law. As the primary net effect of software is to facilitate bureaucratic complexity it is therefor essential that software projects fail if society is to function effectively. In this way the heavy burden of guilt can be lifted from the shoulders of the numerous project managers that have subconsciously devoted their careers to ensuring that projects rarely, if ever, succeed.

Introduction

Many have bemoaned the fact that software projects rarely live up to their expectations, and many are completely abandoned at great expense. When engineers set out to build a bridge a bridge gets built. Our water ways are not cluttered with abandoned structures that cannot be made to work; bridge building is almost always successful. And the constructed bridges almost always function correctly and are usually built fairly close to budget. But when a large team of programers sets out to develop software it is very uncertain whether anything of use will be delivered at all.

Some put this down to organizational culture. If an engineer were to deliberately under specify a load bearing beam in order to cut costs, they would be sent to jail. But when a programmer cuts a corner they get promoted. Others suggest that the problem domains are fundamentally different. But all commentators assume that failure is detrimental. This paper sets out to correct that misunderstanding.

Berglas's Corollary to Parkinson's Law

Parkinson (1955) is a seminal work that analysis the growth of bureaucracy. It proves the Law of the Multiplication of Work, and provides empirical examples that include the growth of the British admiralty compared to the decline in the number of ships, and the growth of the colonial offices during the decline of the empire. The paper develops scientific formulas that accurately predicts the growth of any bureaucracy depending on numerous parameters, none of which relate to the amount of work to actually be performed.

But writing in 1955, Parkinson could not have foreseen the massive impact that computerized automation would have in the following decades. This paper updates Parkinson's law with Berglas's corollary, namely that no amount of automation will have any significant effect on the size or efficiency of a bureaucracy.

Empirical Evidence

To see the effect of the corollary in practice, we will consider bureaucracies whose essential function has remained unchanged since 1955, ie. before computer automation. A good example is the Australian Tax Office.

The first aspect to be automated was the basic processing of tax returns. This included calculating tax due, correlating them with employer documents and the printing and reconciliation of refund cheques. This was performed on large and expensive mainframes that had less computing power than is now found in basic mobile telephones. But even one ancient mainframe could perform the work of a thousand clerks reconciling accounts by hand.

Automation has now spread to all aspects of the tax office. Tax returns are entered electronically over the web, analyzed and processed by a number of complex computer systems, and refunds or payments are processed via direct bank deposits. Most returns are never touched by a human hand. The internal management systems are also highly automated, from the allocation and tracking of audits to processing their internal payroll and benefits systems.

Basic office processes have also been greatly improved. Back in 1955 writing a memo was a substantial undertaking. They had to be written out by hand or dictated to a stenographer. Then a typist from the pool had to be allocated, and any errors required the document to be retyped in full. Moreover only three or four copies could be made unless time consuming Gestetner machines were used, and all copies had to be distributed by hand.

The introduction of the word processor and photocopier in the 1980s meant that memos could be written and copied far more easily. E-Mail systems in the 1990s then provided a mechanism for the efficient and instantaneous distribution of memos to dozens if not hundreds of recipients. The effect of this is that in 1955 the average clerk would only receive a handful of memos each week, and rarely write one. Whereas today even the most junior clerk can receive many dozens of emails every single day.

So given this huge increase in automation, the question arises as to whether a modern bureaucracy could function without this automation? So for our example, suppose we took each and every computer out of the tax office, from personal computers to large mainframes, so that all the processing had to be performed completely manually. Could the tax office still function effectively within the same budget?

The answer is, obviously, yes they could. We know this because in 2007 the tax office's internal budget was AU$11.4 billion, or 1.23% of GDP. In 1955 it performed essentially the same task without automation for A£66.7 million which was 1.33% of the 1955 GDP. The difference is not statistically significant. (Normalizing by GDP (essentially the sum of everyone's earnings) accounts for the growing population and inflation.)

To many this is a surprising result. How could the staggering amount of automation instigated over the previous fifty years not produce any meaningful effect on productivity? This will be examined in the next section but it is an empirical and undeniable fact that bureaucracies have grown, not shrunk.

And for those that would be quick to blame government sloth, similar results can also be shown for private enterprises. For example the banking industry today performs essentially the same function as it did in 1955, when bank accounts were all reconciled by hand. Yet the banking industry has grown 189% as a proportion of GDP.

Effect on Society

Replaced by a Pocket Calculator
The cartoon above was published in the early 1970s (in Creative Computing). It reflected the widespread fear and dismay at the time amongst bureaucrats who understood the enormous power of even a single mainframe computer. However, with an understanding of Berglas's Corollary they now know that they never had anything to fear. Indeed, office work now represents over twice the proportion of GDP that it did in 1955. This is in sharp contrast to agricultural productivity, where the steam tractor and the combine harvester slashed the proportion of GDP in agriculture from over 80% to under 5%.

This general lack of real productivity is clearly reflected in modern lifestyles. Hard working couples struggle to buy the basic food and shelter which their grandfathers had purchased while their wives stayed at home. If real productivity had risen just 1% pa, it would have almost doubled since 1955, which means that people could live a 1955 lifestyle working only three days per week. This is clearly not the case.

Analysis of Unproductiveness

To understand why we work harder than our grandparents despite the huge increase in productivity we have to examine the effect of productivity in detail. Consider the following data:-


1955 2007
GDP £6,670,000 $11,400,000,000
Tax office Proportion of GDP 1.33% 1.23%
Pages in Tax act and Regulations 1,324 15,698
Raw Cost per Page £5,030 $726,000
Cost per kilo page per GDP 1.01%
0.08%

The key statistic appears in the third line of the table. The 1955 Australian taxation act and regulations was published in two volumes, consisting of 1,324 pages plus title pages and index. The 2007 act and regulations is over 12 dense volumes consisting of over 15,698 pages. We see in the following lines that there has in fact been a huge improvement in productivity as measured in relation to the size of the act and regulations that are being administrated. It would be quite infeasible to administer the current act with 1955 technology.

A good example of the benefit this extra regulation brings to society is the Superannuation Co-Contribution scheme which was introduced in 2001 to assist the poor to save for their retirement. It provides that the government will pay an additional $1,500 into each person's superannuation account provided that they earn less than $28,000, have a lazy $1,000 to pay into their own superannuation account, are employed (ie. not house wives or students), and know about the scheme. Thus this marvelous scheme enables the government to be seen to be generously aiding the poor in a way that very few of the poor can take advantage of, and thus costing the government very little. A larger example is the new Goods and Services (VAT) tax, which is essentially the same as conventional income tax but is governed by a completely different set of regulations. Thousands of additions have been made to the act since 1955, and it is the duty of every Australian to comply with all of them.

Given that the size of a bureaucracy is not related to its function, one might ask why the size of the tax office has remained between 1% and 2% of GDP for over fifty years, regardless of the technology available to it. Why not 0.2%, or 35.7%? The answer is that society could not tolerate a value much higher than 2% — we would be paying taxes just to fund the tax collection process. Below 1% is easily affordable, so the bureaucracy will naturally grow beyond that size as predicted by Parkinson's law.

The Importance of Failure

We now see why it is so critical to society that software projects fail. The boundless creativity of politicians and bureaucrats to develop new and more complex regulation is bounded only by the bureaucracy's inability to implement them. The absolute size of the bureaucracy is constrained by external factors, so the only effect of automation can be to increase bureaucratic complexity.

It would simply not have been feasible to implement the Superannuation Co-Contribution scheme in 1955, but automation had made it possible in 2001. Fortunately for society most tax office software projects have also failed, so the act and regulations have been limited to 15,698 pages. But imagine if all the projects had succeeded? We might need to deal with well over 150,000 pages of regulations, and society would be in danger of collapsing under their weight.

Again, one should not assume that these effects are limited to government. In 1955 banking products were very simple. Accounts were maintained, simple and transparent interest calculations were made, and few options were available. Accounts today are much more complex, with clever options to pay additional fees to have interest rates reduced under non-obvious conditions.

A major Australian bank recently undertook a software project to integrate a credit card loyalty scheme with home loan accounts. This promised customers huge savings provided they fitted exactly into very narrow and unlikely profiles. Fortunately the project failed due to the complexity of integrating disparate software systems, and so customers were never burdened with the need to understand, evaluate, and manage the scheme.

Another example was the development of a whole of government portal that the author was directly involved with. Its aim was to centralize and automate the issue and payment of government permits and fees, of which over two hundred had been identified. Fortunately the project was a complete failure, at a cost to the tax payer of a few tens of millions of dollars.

But what a disaster if it had succeeded! Once the two hundred existing permits had been automated hundreds more permits and regulations could have been easily created and implemented efficiently. In this age of "user pays" proposals had ranged from a hair dressing salon operating permit to a pedestrian permit to fund the construction of foot paths. Society was only spared this additional burden by the failure of the software project.

A naive reader might understand the damage caused by software systems, but might wonder if savings could be made by simply not attempting to build them in the first place rather than just having them fail. This of course completely misses the benefit that projects bring despite their failure to directly produce anything of value. Their development employs many bureaucrats, consultants and contractors and their expenditure supports an even larger number of people throughout society.

Conclusion

We have provided empirical proof of Berglas's Corollary, and clearly shown that software does not improve real productivity. Further, we have shown why it is essential that most software projects fail. No one need ever again be embarrassed by participation in a failed software project. Rather they should be proud to have spared society from yet another burden of complexity.

Some may misinterpret this article as satire. Surely it is not really desirable for software projects to fail. But the facts speak for themselves.

References

Parkinson's Law, The Economist, 1955. http://www.berglas.org/Articles/parkinsons_law.pdf

AUSTRALIAN ECONOMIC STATISTICS 1949–50 TO 1996–97 http://www.rba.gov.au/Statistics/op8_index.html

1301.0 - Year Book Australia, 1955 http://www.abs.gov.au/AUSSTATS/abs@.nsf/DetailsPage/1301.01955?OpenDocument

Do Computers Boost Productivity? Andrew Leonard. http://archive.salon.com/21st/feature/1998/04/24feature.html

Australia’s Strong Productivity Growth: Will it be Sustained? http://www.rba.gov.au/PublicationsAndResearch/Bulletin/bu_feb01/bu_0201_3.pdf

Why Software Fails, Robert N. Charette. IEEE Spectrum article listing many failed projects and assuming that that is bad. http://spectrum.ieee.org/sep05/1685

Standish Group: Chaos. Suggests 31.1% of projects are abandoned, 52.7% are way over budget etc. http://www.projectsmart.co.uk/docs/chaos-report.pdf

5 November 2008

Business Model Innovation - case study

Alex Osterwalders stuff really keeps me interested. His work on business models provides great isnight for people like you and me, who need to find the map between strategy and operational level delivery.

Here is a short presentation on business model innovation. It's a case study on the Google books idea.

4 November 2008

Project Desert Storm


It's crossed my mind and it's probably crossed yours. What would it be like to go work in UAE (proabably more specifically Dubai or Abu Dhabi.)

Do any readers here have any experience with going there and getting work? What was the work like, and what was the experience like?