Friday, May 16. 2008
Low-level data mining boosts your business.
Rob Wendes
16th May 2008
Squeak squeak squeak comes the sound of the labouring circular pulley as the ropes bears against it. The smell of the taught, twisted horsehair rope fills the air with the smell of tar as it strains against its load. Crack crack crack the rope sighs as it stretches and folds over the pulley as the load lifts up towards the surface.
At ground level, men and a team of horses strain to pull a huge basket up and down between the levels. A huge shaft hewn into the ground separates the team at the top and the one at the bottom. This is a early miming operation where a shaft is sunk deep into the ground at to a seam of coal. Coal is hewn away from the coalface in all directions by hand hundreds of feet below, and loaded into baskets, which are hauled by the surface crew between the two levels. Bell mining was a precarious operation, where the miners worked in the dim light of candles clearing the seam of coal without pit props to protect them from the roof caving in and burying them all. Bell mining was carried out in North Staffordshire in England to satisfy the early demand for coal, and it demonstrates the divide between each level of the operation.
In your organisation there is a similar division, with the management at the top organising and controlling the mining operation, whilst the people at the coalface hew away at the problems that need to be solved in order to meet the objectives of the endeavour. Communication in both cases is patchy. In Bell mining, the best that could be achieved would be that of shouting instructions down the mineshaft, or by sending a boy in the basket with the load.
Most workers would not have been able to read or write, and even if they did the candlelight at the bottom was too poor to read by; so instructions could only be relayed by the spoken word. It would have been a frustrating process, expecting the boy to remember the context of the message, which they often didn't.
Communication between the levels of your organisation would be much the same with the people at the top seeing the picture at the surface and being in the dark about what is happening at the coalface. People at the bottom are in a different position, where the instructions that are received seem disjointed as the intermediaries add their own interpretation to the big picture.
In a similar manner the information stream reaching the surface passes through a translation process, which is dependent on how much the intermediaries understand what is being said to them.
In the pubs after work, the Bell miners would converse with miners from other collieries in much the same way as the business owners may talk to their contemporaries in the clubs and social places at their level, but the information flow is of a different nature.
The workers talk about the issues that matter to them; how to improve their working conditions, safety, and how to make their daily tasks easier. Owners always create a vision of their business that sells their product and helps to bring in more work or eases the completion of the contracts they have in hand.
In much the same way, engineers of different organisations will work together to solve a technical problem or to overcome a hurdle that is placed in their path, despite any exchanges that are going on at a higher level. In much the same way as the miners, the mindset of the engineer is similar. Making their job easier, understanding the problems of others and coming up with a solution is what their real aim in life is.
When Marks and Spencer, a great British store of the early part of the 20th Century was in its hay day Mr Mark would take the time before the store opened to walk around and talk to the workers at the coalface. He got to understand the issues they were facing and how that affected his business before the message became distorted along the chain of command.
Don't abandon the mineshaft without understand what is really happening at the coalface. Use your engineers to mine information at the lowest level between different organisations.
Thursday, May 15. 2008
The low azimuth of the sun in winter helps to intensify the colours that hit the lens. It would probably take a bit more research to convince myself of this phenomenon, but the sun does tend to be more direct in summer and especially at mid-day.
You will perhaps remember that those pictures you took last summer look much more washed out at noon than they ever were in the early morning or last afternoon. That does pre-suppose that you are a reasonably early riser!
Wednesday, May 14. 2008
Well not really a pond, more a lake, but it helps to illustrate that the South East of England can have the odd cold snap that catches everybody out. Not for us the snowshoes and wheel chains of North America, we are either above that or just a bit foolish.
In reality, the number of times this happens in a year is so small that we can hardly justify the effort of putting chains on our cars wheels. Especially as it’s only for a few days ata a time.
Tuesday, May 13. 2008
Slumbering trees seem to be a bit of a feature in my photography during the winter. I put this down to the skeletal outline they make against the sky, and the knowledge that they will burst into life again in the spring.
This is from a country park near Sevenoaks, called Knoll park. Right on the periphery of the town, it seems to fringe its edge. Being within an easy walking distance it feeds a breathe of air into an otherwise human dominated landscape.
Monday, May 12. 2008
Winters in the UK are nowhere near as cold as elsewhere (maybe Scotland has a closer climate), and every now and then clear blue skies break through to bathe the landscape in weak winter warmth. That to me is the best time to get out with my camera and try to capture some of its bright deep colours.
There I was, strolling through a wood, when I looked up and saw the tree in this picture, which looked stark against the sky. I just had to take it!
Friday, May 09. 2008
When is a Maverick good for business?
Rob Wendes
9th May 2008
The next time you're out of town, take the trouble to find a big open space, which is populated with a herd of cattle. Spend a while with them to see what they do and you will eventually notice that most of the herd stick together. You'll notice that they move as a single unit, and even if spooked by something it is difficult to break up the crowd. There is no independent action.
Now and again you'll find a lone beast, who is most likely a male, and even more likely to be alone if his maleness hasn't been neutralised. This individual has energy and independence, and is much more likely to lead the herd and challenge other males in order to enhance his harem so that he can perpetrate his genes!
This is all very straightforward and logical, and it surely couldn't happen in humankind. Well think again, because people find themselves more comfortable in a group then being out on their own.
Our observant reader will now conduct their own experiment the next time they have the pleasure of a seminar or workshop. There you will see the phenomenon of 'atomic bonding', which is prevalent in everyday life.
Here are a few 'atomic bonds': -
Drinking chums.
Co-workers.
A harmonious married couple.
Football teams.
Coffee-point crush.
Each of these groups can be a very positive force, since these are examples of people working together to achieve a specific end, and that is quite often exactly what is needed to get the result you need. It is that bonding mechanism that gets a Software project moving and ensures that it retains its momentum.
But this very phenomenon can also frustrate every attempt to get over a project's inertia in the first place. People who form into natural groups have a tendency to be mutually supportive to the exclusion of all others.
Atomic Bonds can be negative when they: -
Repel all borders.
Create a shield around the group.
Reject outside opinion.
Become resistant to change.
Can't find an answer to a problem.
Atomic bonds intimidate other groups because they draw on their collective strengths to defend a single viewpoint. It's difficult to break this bond, and when a project is heading for destruction their collective strength protects their group to the detriment of all others.
A single viewpoint is sometimes really good, especially when you need the traction to get a large amount of development work completed, but 'Atomic bonds' stifle lateral thinking and novel solutions.
Enter the Maverick, who in the implementation phase of a project may be considered to be disruptive and counter-productive. When a project has hit the buffers this same influence can be used in a different way.
Even if it is temporary, the 'Atomic bond' needs to be broken, in order that new ideas can flow freely. If your business is big enough, then the individuals can be mixed up to create entirely new teams, from which new opinions and views will emerge. The Maverick is thrown in so that radical thinking will emerge, and unpopular ideas will have to be aired and at least carefully considered.
With the 'Atomic Bonds' broken, there is little opportunity for cliques to form that polarise potential solutions.
If you have a smaller organisation, then although its tougher for the Maverick, organise a workshop, in which you aim to temporarily break the 'Atomic Bonds' and introduce a random element into the proceedings.
When introducing a Maverick you can use an outsider, who will be able to ask 'obvious questions 'and question the established ethos. The 'Atomic Bonds' have got that way because they have something in common that makes them comfortable and shields them from other groups. In your workshop, mix the participants up apparently at random, but in fact make sure that the 'Atomic bonds' are truly broken.
Un-bond the bonded.
Bring in a Maverick.
Break the log-jam in your project.
Thursday, May 08. 2008
One sad even in my life took place whilst we were all tucked up in bed on New Year’s Eve 2007/2008. Sadly the clubhouse at my favourite airfield, Sandown went up in smoke. Here is a picture of the localised devastation, and you might just feel like following through to Isle of Wight Airport.
It seems that some gas bottles at the back of the kitchen were to blame for the fire, and as you can see most of the centre section has been destroyed. The most saddening part of all of this is that the clubhouse housed a Merlin engine from a Hurricane that was shot down over the island.
It’s a huge loss, as you can image, having survived a crash landing and stood the test of time the engine looks extremely sorry for itself, having been charred in the heat of the central part of the fire.
Wednesday, May 07. 2008
I’ve somewhat neglected some of my more conversational categories for a while, and that’s mainly because they seemed less popular than my mainstream subject, but I thought as we plough into summer that I would at least try to reinstate some interest in the non-business part of life.
These entries will, of necessity be a little short and sharp. Watch this space.
Friday, May 02. 2008
How to get a strategic breakthrough in your business
Rob Wendes
2nd May 2008
1930 seems a while ago now, but at that time one man had a vision that would ultimately change the world in a way that was unimaginable at the time. Born in a terraced house in Coventry, he battled against the odds to break through barriers of class and dogma. The established men of wisdom rejected his 'out of the box' thinking as being impractical. Undeterred his tenacity kept him going and eventually the discovery of the Jet engine became a reality. This man was Frank Whittle.
Science, just as in business, has a tendency to remain within its comfort zone and as a result breakthroughs are rare. Much of science merely adds to the general pool of knowledge, inching us slowly forward. It takes someone who is prepared to move out of their comfort zone in business, or science to make an earth shattering change in the way businesses operate.
Think about some the most innovative changes in business:-
The Supermarket.
Just-in-time production.
At the time innovators swept aside current thinking and they moved out of their comfort zone and reaped huge rewards. So why do we stay the way we are? That's because we are comfortable with the equilibrium we have achieved in our life.
You know that your software projects have settled into a steady pattern when.
Poor requirements.
No interaction with the end user.
Poorly executed software development.
Bug-ridden deliveries.
Despite its disadvantages business owners and independent professionals have come to live with the Software they buy as well as the software they sell. But it doesn't have to be that way, if you are prepared to move out of your comfort zone.
The cost of remaining in this comfortable pattern can be much higher than taking a risk that will move you towards higher profits. Use the higher cost of inaction as a tool for arguing for change, and look at your process of producing software to find new ways of improving your performance.
Make a list, like the one above, which states your problem areas. Even if you can't think of everything, just make a small list and add to it as you go.
For each of these challenges make a list of what it costs you to maintain the current equilibrium; (your comfort zone).
For example: -
Poor requirements lead to the wrong product, which reduces the prospect of repeat custom.
No end-user involvement leads to no end-user buy in, which ensures that they will not adopt the product. It also results in the product not fitting into the existing working practices.
For each of these entries on the list, write down what makes you fear change: - For example: -
You fear that adopting a new requirements process will be too difficult to understand.
You fear that end user involvement will lead to impossible requirements, or a task that expands beyond the horizon.
For each of the entries in the list, write down the potential profit incentive for taking action.
For example: -
Improved product reliability.
Quicker development cycle.
Better user experience.
More repeat orders.
Lessening in client resistance to firmer prices.
The potential for profit improvement far outweighs the fear and uncertainty that hold you back.
Make a plan
For example: -
Research new ways of developing software.
Exploit the knowledge of others.
Use an arbitrator for independent decisions.
Training and mentoring.
Cost the plan
For example: -
Research: 20 own staff days @ $350/day $7000.00
Information gathering and documenting: 10 own staff days @ $350/day $3500.0
Arbitration: budget $2000.00
Mentoring: budget $7000.00
Execute the plan
It makes sense to execute any plan that helps you to escape from your comfort zone and reach the next level of profitability. Make sure you help your customers to see how they will benefit from these improvements.
Monitor the plan
Make it work, both for you and your business. Tenacity kept Frank Whittle going, and in the end won him the laurels. Make the right improvements to your business and don't give up on them, because they will improve your profitability.
Thursday, May 01. 2008
I'm compelled to make an impromptu post due to an interesting exchange that has taken place at Masahable.com.
Ruby is a programming language that has attracted some attention over the past few years and it could become an interesting candidate for the next generation of development environments.
As always, there is a hard core of evangelists (entirely necessary people) who live, eat sleep and drink Ruby, and think it's the best thing since sliced bread. As with all of these groups, they get a bit excited when challenged about the effectiveness of the deity they are holding up. I hope, and think, that my posts will give them enough food for thought to get them 'back on the rails'.
The main contention between us is that, in my normal practical way, I have been exploring whether this technology at least meets the level of achievement that of its forebears.
My main bone of contention is that every new technology must always do as much as the last one, at least as well, and add something else to the melting pot.
That doesn't mean that it has to do it all at once, but there isn't much compulsion to adopt a new technology if it's going to give you trouble.
Strangely (but also not surprisingly) the Ruby 'brethren' take it as a full frontal attack, which needs to be repelled at all costs. However it's nothing of the kind.
Let's hope it blooms into a useful exchange where the Ruby camp can get to the stage where their product is the one that we all want to use.
Sadly I'm not convinced we're there yet!
Friday, April 25. 2008
Energize the key to your comfort zone.
Rob Wendes
25 April 2008
Look back to those halcyon days when you were small; had not a care in the world and your Mother and Father took care of your daily life. Perhaps you can remember the energy of life in those days, when you had no compunction about running a race, playing a sport, swimming, diving and burning up your youthful vitality. I used to run around the streets of my local town. Perhaps being a little noisy, but not causing (I hope) too much mischief and just now and again I would stumble on a paving stone or uneven ground and fall and cut myself. If you were like me, it was inevitably the knees that took the brunt of the action, but it didn't stop me making it home with a tear in my eye, to win some affection, some ointment, a plaster and a little down time to take away the adrenaline rush.
Knees heal quickly, and after a day or two the plaster would have disappeared in one of the many adventure with my friends around my local streets, leaving my knees marked with hard globs of hardened blood platelets that we fondly call scabs. Although the scab is part of the healing process, it starts to itch a bit as the knee repairs itself, and like most kids the urge to pick it off, relieve the itching and incidentally expose the sore underneath.
No matter how many times we did this we always ended up with the same result, sore knees and an exposed wound, but for some strange reason this remains in our comfort zone. People, as well as kids, prefer to do things within their own comfort zone, even if it hurts and doesn't work, rather than try something that would take them out of their comfort zone, but that which may be more effective.
Now let's look across the hut at our laboured Software Development project, which is in one of three states.
1. In trouble.
a. You have a problem and don't know how to solve it.
b. You are motivated to get the problem solved and you will make decisions to ensure it gets done.
c. The project has stalled waiting for a Technological answer.
2. Energised and in need of action.
a. You are looking at alternatives.
b. You need tangible results.
c. You need clear courses of action.
d. The project needs a direction.
3. Searching for the ultimate answer.
a. You know where you are going.
b. You are willing to explore the best course of action in detail.
c. You are prepared to commit resources to achieve your ultimate goal.
d. The project is under control but can achieve more.
Our comfort zone shapes us all, how we behave, how we react, what level of risk we can absorb and how much it creates stress are all factors that are difficult to manage one we have strayed outside.
In each of these cases the people running these projects have to manage how they feel about stepping outside of their comfort zone. They are all in similar positions, but have different distances to move if they are going to find a solution to their problem. If this means that they have to stray outside of their comfort zone, then it is difficult for them to move, even if it will make them more effective.
If this sounds familiar, then you are stuck in your comfort zone!
Finding that you make the same old decisions in the same situations and achieving the same mediocre results will not your business to the peak of profitability or win business that will stretch your capabilities.
Your comfort zone could be limiting your success.
It's time for a spring clean and to take the time to change for the better. Next week I'll show you how.
(c) 2008 Rob Wendes, All rights reserved.
I confer the right to reuse and publish all or part of this article or any material from the Tactips newsletter provided that you include a live link to my web site and the following attribution.
"Tactical Tips by Rob Wendes . Please visit Rob's site at http://www.tactips.com for more Software business development articles."
Friday, April 18. 2008
Avoiding 7 project failure traps!
(Don't put it off until tomorrow )
James Joyce's novel Ulysses took some seven years to write and it is not surprising that at some point in the epic struggle he was asked why on earth it was taking him so long. Such writers have a knack of being able to produce the right answer at the right time and it is reputed that he said. "I have the right words already, what I'm seeking is the perfect order of the words in the sentences I have."
Whilst perfection is a laudable aim, we shall never know whether Joyce could have produced a book of the same monumental impact if he hadn't taken so much time. His original objective was that of producing a series of short novels, and it is possible that by fulfilling this he would have achieved the same objective whilst drip feeding his avid followers and keeping publisher and pocket happy!
We are all guilty of failing to make difficult decisions that take us out of our comfort zone, but the truth is that it is better to produce some part of a product early, to help understand what the end game is.
Do some of these 7 traps seem familiar?
Procrastination: You know what you need to do, but there is never enough traction; the project seems to be at a standstill. Your wheels are spinning. Procrastination is the art of keeping up with yesterday (Don Marquis)
Disruption: You start along your charted project path, only to find that there is always something that is insurmountable. No one takes responsibility for deciding the next direction because they fear being blamed for it going wrong. The technical advice always seems to have problems that no one can get to grips with.
In denial: When you are presented solutions you blanche at the thought of stepping outside of your comfort zone. In defending your position you shut out innovative thought and end up with the same result, even thought it is not effective.
Confusion: In the back of your mind there is some panic. The project seems overwhelming and the heavy weight of tasks bears down on you. You need help to straighten yourself out, but if you could make a decision, you don't know whom to choose.
Empowerment. Or lack of it leads to you being over committed with no time to address any of the burning issues that need to be decided immediately.
Blind panic usually emanates from 'no time in the day' syndrome. It doesn't matter how empty or full your order book is, you have no time to delegate, and you have a problem handing over to others, because they might not do the job as you would.
Unfocussed. Ideas brim over and your send people off in all directions to satisfy your enthusiasm. The list gets longer by the day, and it becomes more and more obvious to both you and your employees that you will never decide to take any of them forward. Projects become a flash-in-the-pan, which demoralises and disgruntle those who work for you.
Wariness You are committed, but the more you think about it, the more you feel you need to know and learn to be in a position to take on the task. Maybe another learning course, more debate, more weighing up the pros and cons. Even when you've reached this stage you are still not ready to take the plunge!
These 7 traps lead to some or all of the following.
If you found yourself somewhere up above, or have found yourself there in the past, or think you might arrive there in the future, then join the club.
By taking the same old decisions in the same old way you compel yourself into the same development cycle, every time.
You fire fight your projects now, you fear youwill always fire fight them in the future.
The software you deliver doesn't meet the needs of the client, and you find yourself becoming too comfortable with that. You will always deliver software in panic, time and again.
You always use the same software evaluation process and end up with software that doesn't fulfil your needs. You are remaining within your comfort zone and will have the same problems over and again.
Break the mould, help is at hand! Moving away from a habit is difficult, and to help you, there will be more in future newsletters; but don't forget that all of the tools and services you need to make you comfortable outside of the zone can be found by clicking here >Comfort zone
By subscribing to the Tactips newsletter you have taken out your first piece of insurance. If you haven't already done so click here to sign up for weekly tactical injections into your business knowledge.
(c) 2008 Rob Wendes, All rights reserved.
I confer the right to reuse and publish all or part of this article or any material from the Tactips newsletter provided that you include a live link to my web site and the following attribution.
“Tactical Tips by Rob Wendes . Please visit Rob’s site at http://www.tactips.com for more Software business development articles.”
Friday, April 11. 2008
Against the odds!
On
14 Dec 2007 one man had a
difficult decision to make. His destiny was about to be changed upon
signing a contract that would propel him into a wild and exciting new
world. At the time he signed he knew that his biggest challenge would
be communication, but this didn't hold him back from the challenge. In
little over a month he would tie up the loose ends where he was and be
ready for the challenge of his life. He had made a life changing
decision although he knew he had a mountain to climb, which would deter
many of your contemporaries.
Tidying up the last remaining business, he looked only once behind as
he trod the last few steps up into the aircraft that would take him to
his new life. The three hour flight was a busy one, as he consulted and
contemplated how he would handle communications when he arrived.
As the minutes ticked away he knew that he needed to be prepared, for
as soon as he touched down a wave of media people would surround him,
each one wanting answers before he had even settled into his new role.
But it wasn't just the hurdle of managing the media that would give him
the greatest challenge of his life; his biggest hurdle at this point
was communication.
The first of what would become many press conferences was not only
difficult, but also more of a challenge for many people. This man was
used to the media, and was wary of committing himself to any comment
that would be taken out of context. The tension was much higher than
normal as he entered the room, and the glare of camera flashes engulfed
him. As he sat preparing himself for the first question, he knew of an
additional burden that he would have to overcome, a language barrier
that extended beyond the semantics of lost words between different
generations. This man was Fabio Capello, an Italian who was now the new
coach for English football.
http://www.thefa.com/England/SeniorTeam/NewsAndFeatures/Postings/2007/12/Capello_announcement.htm
Not only must he manage the English football team, but he must also
handle the press with his faltering English aided only by an interpreter.
It might seem absurd that I could draw any parallel between this
situation and a successful development of a Software project, but a
little reflection will show how close they are!
Most people who manage Software management projects are not technically
literate. That is not necessarily a disadvantage, especially if we
consider the problem that Fabio Capello had to overcome. Instead of
shying away from the problem or hiding from it, he tackled this
communication problem head on using two measures: -
His first tactic was to employ an interpreter, a job that can only be
achieved by someone who is in tune with Capello. Just think what would
have happened if the interpreter didn't have any knowledge of football
or the tactics used by the media. Our language is a minefield of
evolving idioms, which we understand through common use. An
example might be when we say that we can finish a job 'standing on our
head'. I'm sure that doesn't translate directly into Italian!
His second tactic is to start to learn the language and hence break
through this barrier, so that he would no longer rely on the
interpreter. This is a longer term aim, when you think about it, since
Capello has to change his mindset, understand the idiosyncrasies of the
language, the humour and the inferred meaning.
Capello's ability to manage both his team and the stakeholders around
him is directly affected by his ability to communicate across
boundaries. When managing a successful software project the same is
true. A small to medium sized business will rely on a high level of
communication across the layers of management; the quality of which
will depend on how well tuned the management are to the language being
used at each layer and who interprets if for them.
If you don't understand the technical issues surrounding your
decisions, then how can you hope to become a world-class leader, like
Capello? You need to choose an interpreter who will break down the
language that your organisation is using in order to understand the
financial decisions you are making. Article such as this are written in
a way that helps you to see how to tackle the problems that cause
inertia in your business.
By subscribing to this blog you have taken the first step.
Saturday, April 05. 2008
I expect the title to cause uproar and offence. After all UML has become the bedrock of the development community since about 1994 and I'm sure that the software architect or software developer who is working for you will raise their hands in horror at the thought that their hallowed design notation has come under fire. I am often asked why I don't use UML to convey my message in the tutorials and Technical Information Packs (TIPs) that I write. It's quite simple really, UML is a specialist technical notation, and it's one that I believe Business Owners and Professionals don't need (or want) to master in order to understand the Software Solutions that they are presented with.
The Unified Modelling Language is Unified, I agree, ever since two gentlemen called Rumbaugh and Booch decided it was a good idea to compromise over their diverging modelling ideas rather than slugging it out. They avoided the VHS/Betamax war of software modelling. UML does allow you to model the relationships and behaviours of a set of interconnected Software objects, but can it be termed a Language in the true sense of the word? Languages are used to aid communication between people in the same country and culture, and the defenders of the faith would argue that it does this within the Software development community. UML certainly doesn't do that outside of that narrow band of followers, and indeed can strike terror into the heart of the person buying your product.
When inspecting the claim from within the community a few cracks begin to form. When agreements are reached between two dissimilar modelling approaches you might think that a few compromises had to be reached along the line, and that is truly the case. UML describes quite a number of diagrams which can be used to improve 'understanding' of the problem, but it is left to each community to decide exactly which of these modelling techniques adequately describe their solution.
You can end up with a Software Architect with one view and a developer with another, and like all things in software neither is right or wrong! I can almost feel your puzzled expression pushing back across the Internet. How can a Software aficionado be tilting at his own windmills? I am quite happy to help you understand more of the language of the Technophile, through these pages and that could well be the answer for you. However, I also think that there is plenty of room for Software professionals to provide a plain English alternative that the people who pay them can understand.
So, in my view UML is bad when you are trying to share knowledge across a broader community, and also can be self defeating. But the bottom line is that until another 'Modelling technique' comes to light, then we are stuck with it. The divide between the technical culture and the rest of the world can only be crossed if the Software elite learn to communicate clearly and effectively.
Friday, March 28. 2008
Since its inception, the Cinema has harnessed conflict as a tool to lure and entertain its customers. It seems inevitable that we have a need for excitement and adventure that can be safely served from a displaced standpoint. We can enjoy, for instance, a 19th century naval battle, such as ’Master and Commander’ from the safety of our Cinema seat, absorbing the excitement suspending life for a short while whilst we lose ourselves in another world.
All too often, what we see, is the perfect collision of forces that seamlessly bring together the men and materiel who successfully execute the goals and aspirations of some higher order. We are in no doubt that their objectives will be met, even though in the short term there are obstacles to be overcome. Often these obstacles provide the excitement on which the whole plot relies.
As we watch we see the commander setting the objectives, detailing the officers and men, and leaving it to each group to fulfil the obligations that have been placed on them. We know that it isn’t always going to go according to plan, but we also know that each unit will work independently, but to the common good. We expect the Commander to take an active part, to oversee the men and to take action when the battle isn’t going entirely to plan.
Since all of this takes place in the ‘fog of war’ it would seem logical that such actions were doomed in the chaos of battle. History has shown that some, such as Nelson and Wellington knew how to get the conflict won, whereas others such as Douglas Haig have won notoriety.
So how does this help us with Software? Well there are quite a few parallels from which we can learn. I would execution of some endeavour that relies on Software or a Software product is no different. After all there is a collision of people and materiel, which at time can resemble a conflict, and after many skirmishes and battles the winning leader will prevail.
Whether the product is fit-for-purpose or worthwhile outcome will be the subject of much debate, but setting politics aside, what makes one endeavour successful over another?
To a greater extent the outcome is dependent on the culture in which it is produced. Although in my earlier example, the British Navy relied on unquestioning obedience for its success, it could not have succeeded without the following: -
1.A common aim.
2.Clarity.
3.Clear goals and objectives.
4.Independence of action.
5.Individual reward.
These days, unquestioning obedience is difficult to impose especially when a Software development project relies on high calibre staff. Whilst not advocating a café culture, a co-operative organisation is more likely to win if they follow these same rules.
|
