IT Job Market May Improve in 2011

CareerBuilder surveyed IT managers in the United States in charge of hiring. The job site subcontracted the interview work with these IT managers out to Harris Interactive, which did surveys from November 15 through December 2, 2010.

When the numbers were all tabulated, 42 per cent of the managers contacted said they planned to add permanent, full-time IT people in 2011, up from only 32 per cent who said they would hire full-timers in the IT department a year ago. Sixty-six per cent said they will be increasing the compensation of their existing IT staff in 2011 – the average expected pay raise works out to 3 per cent – and 56 per cent of those polled said they were worried about losing their best employees as the economy continues to improve. Salaries for new positions are expected to go up by between 1 and 3 per cent.

British Gas sues Accenture!

British Gas is suing Accenture. Accenture put in place a SAP based system which led to massive complaints against the gas supplier. It turns out that Centrica, British Gas parent, wrote off about 300 million dollars following errors with the system.

British Gas is seeking a multi-million pound damage for the installation of the billing system, which, “caused huge disruption” for the company and its customers. British Gas claims the billing system was riddled with “millions of errors.” Accenture is claiming this is “inaccurate” because it was probably on one million errors not millions, but who is counting.

A preliminary appeal brought by Accenture against British Gas was tossed out by an English judge. “British Gas is now one step closer to holding Accenture to account for the disruption caused to our customers.”

This lawsuit is paving the way for other “users” to sue its outsourced IT development.

Scaling Music and Software

I am working on a lecture for my economics class about production theory.  Production theory works nicely for software development, music and    information workers too.

Output is the result of labor and capital.  The amount of music produced is the result of musicians (labor) and instruments (capital).    As more and more musicians are added to the process of making music the process of making music becomes more formal and there are overhead costs.

If we start with one musician playing a piano, then there is not much overhead required.  Add  three musicians and you get a quartet and there is some communication that needs to take place.  Add about 96 more musicians and you get an orchestra.

The cost per output (the average product) begins to rise because you have overhead costs.  If you have about 100 or so musicians you need a conductor.   Sheet music is required too (formal documentation not necessarily required for a small group).  We see the marginal cost, the cost to produce additional music, begins to rise.  The reason are additional labor is required that does not produce music directly.

This same model works for software development too.  Output for software is the amount of functionality produced.  As the project scales upward formal processes are just required.   There project resources (labor) required such as a project manager.  Formal methods and documentation is required to help in communication.

So there you have it…. Production theory works for information workers.

The End of Vaporware?

Software companies are being held accountable for problems in its software projects, misrepresenting what a software product does and being deceitful project timelines. A British judge also said the Red Sky software development company should have better understood the requirements of its customer. An earlier court ruling found that EDS misrepresented project timelines and was what its software product actually did. It sounds like the end of vaporware.

Red Sky sold hotel management software to London’s Kingsway Hall Hotel but the Hotel found problems with the software immediately. Kingsway Hall complained and called customer service and got customer no service instead. The software company knew of problems with its software and failed to disclose those problems because it wanted Kingsway to buy its software. It is simple as that. The question remains should a software company disclose known issues to its customers. It turns out British courts are saying yes. Red Sky should have told its customer of problems with the product when demonstrating it and chosen more demonstrations for it that more closely matched the customer’s own business requirements, the Court ruled.

Does any other industry believe or think they should not be held accountable for product flaws that may cause its customers harm or injury. Red Sky tried to rely on a clause in its standard terms and conditions which said that the only remedy available to customers if the software did not perform as advertised was to make use of its maintenance and support functions (a.k.a. call customer service).

Clause meant that Kingsway could not sue it for a refund on the software or for the additional costs it incurred as a result of its failings. The High Court disagreed and said that Red Sky’s clause was unfair under the Unfair Contract Terms Act. It said that this Act applied and protected Kingsway because negotiations between the companies had been one-sided on the issue of liability. His Honor Judge Toulmin also said that the software was not up to the tasks that Kingsway needed to use it for, and which Red Sky should have known were part of Kingsway’s needs when buying the product.

This decision is on the heels of an earlier decision. The High Court ruled that EDS had lied about its software when selling it to BSkyB and awarded interim damages of £270m (about $400 millions) against the software supplier – ouch! The court also agreed that EDS had been deceitful in pursuing the contract, finding that the information technology company had deliberately misrepresented how long it would take to complete the job. BSkyB Wins Legal Victory Against EDS -

http://online.wsj.com/article/SB10001424052748703906204575027303086931726.htmlHigh Court rules software liability clause not ‘reasonable’ http://www.channelregister.co.uk/2010/05/12/red_sky_liability_ruling/

Marginal Cost

Marginal cost is different from Average Cost.  Average cost is total costs divided by total functionality created.  Marginal cost is the cost of adding one more unit of functionality to a software product.

Why is this concept important for software development?

The marginal cost curve looks something like the Nike Swoosh.   Marginal costs rise as software projects get large.  The reason for this is many software organizations do not have the discipline and necessary infrastructure to support large scale software development.   The fewer infrastructures the faster marginal costs will raise. 

In other words if you try to build something that is large and you do not have the skill set to build it the unit costs are going to go up rapidly.  People are going to be standing around looking for stuff to-do.  

Organizations need to find its sweet spot where productivity or unit cost is the lowest.

Published in: on December 30, 2009 at 01:01  Leave a Comment  
Tags: ,

Industry Averages Software Productivity

I got an interesting email from a person asking about the variations in software productivity industry averages. I believe the person already knew the answer and was just looking for clarification.

There is no such thing as an industry average cost for software development and there is no such thing as an average industry wide cost for construction either. Since the cost per unit of developing software is so varied, knowing the average cost to develop software is about as useful as knowing the average cost to make something.

1. Productivity varies based upon the size of the project. The larger the project the lower the productivity (higher the unit cost). A project that is 5,000 function points is going to cost more per function point than a 500 function point project. This is true in construction projects too. A sky scrapper is going to cost per square foot (or square meter) to build than a single family dwelling (holding everything else constant). Software development has diseconomies of scale or increasing marginal costs.

2. Software productivity rates vary by type of industry. The software productivity rate for software developed for the health care industry is different than software developed for the banking industry. A medical office is not going to cost the same per square foot (or square meter) as a bank.

3. The way data is gathered will impact software productivity rates. Since I work a lot on mergers and acquisitions, I include everything and everybody not just the IT staff or programming effort. I prefer to use payroll reports and expense payment reports and not just data from time reporting systems. The typical gap between payroll and time reporting systems can be up to 50%. In other words, most software organizations under report its true cost by about 50 percent.

Read more at Reboot! Rethinking and Restarting Software Development

www.RebootRethink.Com

Published in: on December 28, 2009 at 11:29  Leave a Comment  
Tags: , ,

Ideas on Productivity

I stumbled upon a very good blog related to productivity and I thought I would share it.

http://www.productivity501.com

Published in: on October 30, 2009 at 09:11  Leave a Comment  
Tags: ,

What we have here is a failure to communicate

Why do bureaucracies emerge in organizations and often overwhelm it?

The real question in my mind is, “What is the root cause for an organizations to have too much bureaucracy?”  It is not like organizations or more correctly individuals within organizations wake up proclaiming we need more bureaucracy.   People do not say, “We need to burden teams with status reporting, forms, procedures until we reach a point in time where everything comes to a screeching halt.”

The idea of small autonomous teams that are unhampered by bureaucracy is not new.   During the 1990’s there was a software methodology called Rapid Application Development (RAD) and today the buzz is Agile. This idea of limiting bureaucracy is not limited to software development.  Going all the way back to the 1940’s there were teams called “Skunkworks” at Lockheed Martin.   The point being idea of self directed teams is not unique to software development and not a new idea.

Some of the clues for burdensome processes come from the word bureaucracy itself.  The term bureaucracy came into use shortly before the French Revolution of 1789, and from there rapidly spread to other countries. The Greek suffix – kratia or kratos – means “power” or “rule”. Does it turn out that bureaucracies are the result of power and rule?

My experience tells me it is not that simple. The root cause for bureaucracies is the result of poor communication.  The cause of bureaucratic burdensome processes is the result of a failure to communicate.   An organization can eliminate burdensome processes, but it does not resolve the problem of communication.  If root causes are not addressed, then problems will never be resolved.

The bottom line is  bureaucracies emerge because of poor communication.  Go though the two links below and look at the recoomendations.  We will begin to notic the opposite is done in software development.  As an example, it is recommended to avoid jargon.  How often is that done in software development.

99 Ways to Improve Communication http://www.getinfrontblogging.com/communication/99-ways-to-improve-your-communication/

Improving Communication Skills http://achievesuccessforlife.com/41/improving-communication-skills/

Sources

http://en.wikipedia.org/wiki/Skunk_Works

http://en.wikipedia.org/wiki/Rapid_application_development

http://en.wikipedia.org/wiki/Bureaucracy

Methodologies and Fad de Jour

According to a recent study Agile is growing in popularity and not long ago the Capability Maturity Model (CMM) was the fad de jour. CMM was based upon sound scientific methods with plenty of data to support its case and Agile is based upon anecdotal evidence. It is not like there are small tweaks of ideas because the difference between CMM and Agile are tremendous.

What is it with software development that causes it to flirt with methodologies as often as weight loss methods? It is like the industry is floundering. It seems that some of the major consulting firms and experts in the field were proponents of CMM not long ago singing the praises of Agile. There seems to be an effort to support and to promote what is popular instead of what is right.

I believe the clue lies in why so many individuals experiment with weightless methods. Consumer Reports declared Weightwatchers the best success weight loss program, but its success rate is low. It is estimated that 95% of those using Weightwatchers eventually return to their old weight. It turns out people (especially Americans) do not have disciplined eating and exercise habits. It is so easy for us Americans to be overweight, to sit in front of the TV, or to spend countless hours surfing the internet. Our portions at restaurants are supersized and there is often an endless supply of snacks at work.
We could excuse the ebb and flow of methodologies on fact the field of software development is in its infancy stages, but I am not sure that is a good idea. In reality, those software companies that are the most disciplined have the highest rates of productivity and quality. This is true of world class athletes and musicians as well. It is especially true of world class golfers. A logical question is what does discipline look like in software development?

What makes software unique from other industries and disciplines is it is so easy to be undisciplined in our methods. It is easy to change a line of code compared to changing a physical structure or a building. The rhetorical question becomes if physical structures of a building could be changed as easily as software can be changed, then would architectural firms adopt the methods of software development?
I have studied hundreds of organizations around the globe as part of a merger or acquisition. It turns out those that are the most disciplined with repeatable processes are the most successful. It is critical to note that being disciplined does not guarantee success. It seems the missing ingredient is customer knowledge. The formula becomes those organizations with discipline and those that study the customer are the ones with world class performance levels.

Yet the unanswered question remains.  What are the reason so many software development organizations flirt with so many methodologies?

http://www.googobits.com/articles/625-the-skinny-on-fad-diets-what-really-works-what-definitively-doesnt.html

http://www.RebootRethink.Com

http://www.internetnews.com/dev-news/article.php/3841571

http://blog.nayima.be/category/agile/

http://www.sei.cmu.edu/cmmi/

Movie Making and Software Development

The role of the project manager and software manger are often missed understood. Movie making and software development are very similar types of creation.  A brief examination of movie making and comparing the roles of director and producer will give some insight on the differences of the project manager and software manager.

The director of a movie is similar to an IT Manager.  They are responsible for day to day activities.  It is common for many directors to not have any acting experience.  For example Steven Spielberg, winner of numerous academy awards, has never acted.  On the other hand Clint Eastwood was an acclaimed actor prior to becoming an award winning director.  The directors, like an IT manager, is responsible for the management of staff.

There are many technical aspects the film producer need to coordinate.  Besides the actors and actresses it is important to have the right film crew, lighting, sound, editors, animators, so on and so forth.  The producer may or may not have intimate knowledge of any of the technical roles.  The software project manager is responsible for getting the right business analysts, coders, testers, software engineers for a project.

Producers like the software project manager are responsible for the planning and the execution of the budget and insure the project comes in on budget and schedule.  An executive producer may coordinate the activities of several producers similar to the role of a project management office.

———————————————-

Who does what? http://www.directortom.com/director-tom/2007/8/17/executive-producer-producer-director-who-does-what.html


A production manager – a rose by any other  name

http://filmindustrybloggers.com/blog/2009/10/13/the-production-manager-a-rose-by-any-other-name%E2%80%A6/

Follow

Get every new post delivered to your Inbox.