Rob's Virtual Home
Home arrow Productivity arrow Productivity revisited Sunday, 05 September 2010
Main Menu
Home
Rob's introduction
Rob's personal stuff
Rob's fav links
Rob's guestbook
- - - - - - -
Productivity
Page 2
- - - - - - -
FAQ
FAQ definitions
- - - - - - -
Favourites
Recently published. Check this out !
 
Productivity revisited E-mail
User Rating: / 0
PoorBest 
Written by Rob   
Monday, 09 March 2009

ImageThe profession of Information Technology is at the beginning of its next phase: true industrialization. And true industrialization is a lot more then offshoring, transfering work to low-labourcost countries, alone. It's also about standardization, automation and re-use but what's even more important, about a reproducable and predictable process of designing, producing and implementing software. Although some are still a bit reserved and may be even on the defensive, the bar is already high and now even pushed further due to the current economic slowdown. The demand is a lot more value for less money,within a shorter time frame. Productivity is the keyword but in fact it has many faces. Time and money are not always interchangeable anymore mostly due toavailability of current high technology standards. And on top of that, producing software efficient is not the same as producing effective.

Let's have a closer look.


 

  • ImageTime efficiency serves speed. The main goal is to produce software faster or more given an amount of time. It's a professional view and measured with metrics like the Productivity Index (PI) or time perfunctionpoint (h/Fp) or usecasepoint (h/UCp).
  • Cost efficiency is all about reducing cost off course. Everything you can do to make software cheap from deploying offshore labor capacity to the use of "free" open source components is worth a try. It's usually a "purchasing" view and often squeezed into fixed-price contracts. Measured in cost per functionpoint ($/Fp) or usecasepoint (h/UCp) or cost per activity/discipline.
  • Time effectiveness or effectivity is about how much (software) you (could) produce if all available labor is used in the right way and without any losses at all. There is a funny anecdote about this. A countries political frontrunner one day announced the great news that the productivity last year had grown 0.5 % above expected. Of course as a result of his vision and guidance. The next day an econometrist damped all enthousiasm by explaining that Christmas that year covered a weekend with a productivity gain of almost 1% to be lost in the next years again!!! This factor is more or less a (IT) business-management concern but still important for projectmanagers too. It can happen that all projects are running just fine without any overruns, but the department as a whole is in red figures.
  • And finally aiming with cost effectivity, the main target is doing exactly the right thing and not more than needed. In fact it's all about getting the maximum effect given the available budget. One could ask if this shouldn't be always the case? Well yes, but usually there is a gap between what was really really needed and what is made in the end. The difference between "must have",  "should have", "could have" and "would have" is apparently very difficult to manage. The 80/20 rule is the one to cherish.

 

 

All of the above is of course given a certain quality, technically and functionally. However, there is a tendency or risk that quality is at stake when aiming for cost efficiency and/or time effectiveness. Often the wrong level or type of professionals is assigned on the project. For the very short term that seems to reduce cost but will probably backfire with the # of defects later on in the project or during maintenance. On the other hand focussing on producing more or faster (time efficiency) or exactly the right functionality (cost effectivity), usually involves the assignment of better educated and more experienced resources and therefore reducing risks and loss of quality. When managed sensibly, u might end up with the holy grail, having improved everything.

So again, why is this disctinction between these 4 views on productivity important? Well, because measures u would take to improve either one, could seriously have an unfavourably impact on another. Of course this contrast is not 100% and there is overlap. Reducing cost will not always delay the project for example. Beware, everything is connected to everything. So u only have to make choices!. May be i should add a line to my fav tile: 

  • say what u do
  • do what u say
  • prove
  • improve 

and start it with 

  • know what u do Foot in mouth  

Anyway, the IT-profession is already at a level that silver bullets to improve everything are hard to find. Measures taken nowadays usually focus on a specific goal and some measures even influence other goals with a negative effect. For instance, implementing an application to beat the competition in a time-to-market battle, is more expensive than one without any time-pressure.

Nevertheless, there is of course a number of productivity influencers which at least should be taken into consideration before moving to the more fancy solutions and tools. In general, they are about people and proces, management and (offshore) governance, focus on results and quality in all disciplines and last but not least proper architecture and requirements specifications. Not really eye-openers one never thought about, but if implemented professionally, in essence the road to improvement and success.

Although a Capability Maturity Model like CMMi and a method DMAIC(Define - Measure - Analyse - Improve - Control) from Six Sigma already gives alot of guidance to continuously improve, the best way to move is release by release with clear focus and targets. Assuming that already a certain level of professionalism was already achieved, the danger of just looking at the "high priorities" is that they're not always enforcing each other or they even might conflict. Just bundling a number of improvements and "give it a go" could result in an improvement of the quality of life no doubt but hardly any visble or measurable results. IT-projects take some time anyway so it's already difiicult to predict and measure the quantitative result. It's better to combine a number of measures belonging to the same area to have better visible impact simple because things add up!

And finally, the best part of proper productivity improvement is resilience. Having an impressive set of accelerators coupling people, process and technology (governed with focus on the business goals), is the best starting point for agility and may be even survival. It protects the organization for economic pressure and in better times it enforces growth.

Have fun being productive! Money mouth


Add as favourites (18) | Quote this article on your site

  Be first to comment this article

Write Comment
Name:
Comment:



Code:* Code

 
< Prev   Next >


GO TOP!
Time
 
Select direct !
Click on the slide!

Industrialization

It's a bit more than offshoring alone.

Click on the slide!

Descartes

What if Artifical Intelligence supercedes a human brain?

Click on the slide!

Productivity revisited

Productivity is about speed. Or costs? Or effectiveness? Or ...? Gee, I'm confused!

Click on the slide!

Mythbusters

A standard method for all projects? BUSTED!

Click on the slide!

Methods take 2

Developing a method is hard. But deployment is harder. And what about the one-method-fits-all myth?

Click on the slide!

Agile revival

Is it only about being fast and no documentation?

Click on the slide!

Languages

Speaking and writing different (programming) languages is only human?

Click on the slide!

Money for nothing and content for free

uuuh

Content as the "wrapping" for services only?

More...
Click on the slide!

Offshore - Onshore

Is there still a diff in on and offshore? Or r we ready for real global delivery? What r the opportunities?

Click on the slide!

Productivity interview

Do people really know what they want with productivity?

 
 
Advertisement

© 2010 Rob's Virtual Home
Joomla! is Free Software released under the GNU/GPL License.