On occasion, usually during times of corporate stress or when high levels of change are occurring, the “calibre” of people can be drawn into question. “Calibre” is one of those deeply meaningful management metaphors that hides its completely subjective nature and is often regarded as a binary switch or a gauge. In the long run; someone either has the calibre or they don’t.
Design patterns are – to most established and successful software developers - reusable, known good starting points for specific applications in writing software. They are proven, best answers to some of the most basic problems encountered when writing code. The seminal work on this subject is the eponymous 1994 Design Patterns or “Gang of four” book, which deals with design patterns for object orientated programming. There are several types of pattern: constructional, structural and behavioural and latterly even more. They have names such as Singleton, Facade and Mediator. In simple terms they provide a way to stop software engineers from assessing and reinventing common solutions time and time again; if it needs to roll, these are the plans for the wheel.
My experience in working in systems and software development has often required the same answers to the same questions. How do requirements get written? How should the development process work? How do we prioritise our projects? Why can’t we deliver on time and to budget? How do we maintain our software? Fundamentally, the answers to these have been, in essence, the same, the foundational structure of the answers being common, from large global businesses to small niche players.
Whilst large scale frameworks like ITIL and Prince can provide best practise in terms of execution, I am not sure they provide the actual pattern, more the instructions and rules. They seem to err away somewhat from the foundational definition, or even assume it is already in place. This enables generic suitability, but what role could specific patterns for these common, business challenges play.? What would a prioritisation pattern look like? What would an estimating pattern look like? A peer review pattern…
Some formative work on this subject has been done, certainly in the 90’s, but there is little published specifically for these more process based patterns; the capturing of wisdom to enable new businesses to learn from the established. To have some of these patterns would save the effort and waste of rediscovering how to fundamentally operate as the start-up spark fades and maturity needs to prevail. I am wondering where these patterns are, perhaps they are locked up in the “IP” of integrators and consultants, but surely there is enough experience out there to bring them into the open.
More to follow…
I have been wrestling with a specific issue of how to present a view of how a project led business needs to be “knitted” together to ensure delivery. I am sure that there is “best practice” material for this but it has to be specific.
I decided on four layers:
|
Authority Decisions informed by the Business Strategy and capability Management Control and governance of the execution of business decisions Lifecycle Frameworks where tasks are organised to deliver in the specific context of the business Process Tasks with assigned roles and responsibilities amongst your people and partners |
With this simple, top down model it should possible to define and explain an integrated business management concept that will support a project led approach to delivery.
I said I would review Jeffrey Pfeffer’s latest book, What Were They Thinking – Unconventional Wisdom About Management after reading an interview with him on Guy Kawasaki’s blog. It is a good book providing a number of short articles he has published in the magazine Business 2.0.
There are some great articles in there, my favourites being The Whole Truth, and Nothing But, Why Spy on Your Employees and How Companies Get Smarter. Jeffrey recommends that the book is read in the order you want which had me reading in interest order priority. The good thing about that was that I was expecting to not finish the book and for the later articles to be less interesting to me. Surprisingly, I was reading to the end, in fact looking for the ones I’d missed, only to find I’d read them all.
The questions from my original post still stands however; why wisdom like this still fails to enable businesses to consistently improve performance and make positive progress. It is almost as if there is an anti-logic at work in some businesses, where ego and personal agendas distract focus from a simple approach to building a strong, collective team of engaged and effective people. Obviously, it isn’t always easy, but plain, respectful people management and instilled corporate values around truth and openness will put most businesses on the right path. Yet, so many are consumed with internal politics, fear of mistakes, fear of change and strategy and are crippled by ineffective and unaccountable people. It defies reason in my opinion when so much information and good management practice is so straightforward.
I shall write more on this in the future, trying to understand better what the causes of this kind of management malaise are and see if there is an effective way to provide an antidote for it.
In my previous article about Software Project Entropy I discussed various employee types often found in software companies. Due to the inherent technical and often very complex environment, it is not uncommon to find employees that become highly specialized. In my article I indicated that The Specialist is a role holder that revels in his craft, enjoys the limitation and highly pointed focus he has and thus the power that he holds. Often these people will hold on to their knowledge, as after all “knowledge is power”.
When an employee is not so bothered with retaining her current position and status, is more self stretching and expansive, she can rapidly turn into The Prisoner. This is an individual who is not allowed to diversify, is kept in a role for his specialist skills and is considered too expensive or risky to replace. She may posses unique knowledge and know-how, she may be core to the business and ignored or overburdened with responsibility. She will be unhappy, searching for new projects and generally frustrated. All of these things will be because she cannot be released from her current responsibilities.
Guy Kawasaki’s recent interview with Jeffrey Pfeffer contains an insight into Jeffrey’s new book, “What Were They Thinking, Unconventional Wisdom About Management“. It is interesting when reading this that the majority of Jeffrey’s answers seem to be pragmatic, common sense, but it is inevitable that Guy’s questions are probing around common issues most businesses experience. I’m interested to understand why such compelling wisdom still fails to enable businesses to consistently improve performance and make positive progress. Perhaps it is that although the truth can set you free, so can a lie. I’ll read and review this book in due course.
Why do it? To save money? To increase capability? To buy skills you don’t have? To be able to “FLEX”? Over a series of posts, I will describe my experiences with software development outsourcing and try to answer some of these, and other questions.
Offshore development to save money?
I don’t want to get into penny pinching here, but in my opinion, that’s all you’re likely to save. On a time and materials basis, the costs for offshore development are alluring to say the least, coming in somewhere between £80 to £150 per day for labour plus the standard prices for software tools etc. However, rarely can this cheap labour be effective from day one, there is always a learning curve that needs to be overcome. Even the most adept C++ developer will find it challenging to sit with the perfect design specification and just get coding, with no background. So there is a toll to pay to get the offshore team up to speed.
Tweet This Post links powered by Tweet This v1.3.2, a WordPress plugin for Twitter.
![[Post to Twitter]](http://www.matanza.net/wp-content/plugins/tweet-this/icons/tt-twitter.png){kind=icon}