the Bridger

March 6, 2010

Project managers must be consultants and must behave like consultants – it’s a bad day for “permies

Filed under: Knowledge management, project management, soft skills — Tags: — admin @ 3:03 pm

Ed Taaffe has enjoyed a twenty year career in management with the past ten years spent in Project management and takes a special interest I human motivation as a management tool.  In this piece he explains why the consultant relationship with the client and the project team is critical to the success of projects.

This argument has nothing at all to do with the perennial  disagreements between Contractors and “Permies” in the IT industry, though it does go part of the way to proving the contractor viewpoint right.

What does success look like?
First let me be specific about the project failures we are addressing. There are all kinds out there and as any good problem solver or six sigma practitioner will tell you, there is more than one way to apportion blame and define cause.

What I am specifically addressing  is the high proportion of projects that get closed down,  or arrive late enough , or sufficiently over budget, or of sufficiently low quality to be deemed a failure.

These projects all started off wit everything in place and going fine, then at some point they began to drift and continued to drift unchecked until they ended up a failure.

My assumption is that since many projects defy totally accurate prediction of time and cost, there is a built in expectation that budget, scope and or duration may have to move at some point, if this is done and agreed then there is no project failure. Project failure occurs when the rot sets in and it is ignored, or when the project is set up with immovable boundaries and finishes outside of them.

Knowledge management holds the key

Within the technology world there is a particular inability to understand the nature of knowledge and it is mostly equated to data, or at best and not often, to information. The trouble is that neither of theses viewpoints is helpful.
 It is OK to believe that a  software process demands a precise piece of data to work correctly and to live in a virtual world of absolutes as do many technically minded people, but that doesn’t wash in the real world and there lies the corpse of many a CIO.

in the real world of doers, makers and shakers, decisions are made by people and the key ingredient is not the data, but the implicit and tacit elements of the way the people interpret information.

Bear with me, I’m almost done with the boring stuff.
Cognitive Dissonance

Leon Festinger produced a study in 1957 at Stanford University whereby he clearly demonstrated that when somebody has reason to present an argument that is actually at odds with what he believes, he naturally alters is opinions as a result and finds himself agreeing much more with the argument that he previously disagreed with strongly.

It’s not hard to imagine how and why this might occur and there is plenty of further work exploring this aspect of the phenomenon of Cognitive Dissonance, however the most interesting part of the experiment carried out by Festinger demonstrated that when a reward, or threat was used to force, or induce the person to argue against his own beliefs or judgement, then the effect of Cognitive dissonance was lessened, or missing altogether.

Clearly the mind has no trouble in understanding the idea of being paid to hold an entirely objective opinion, which it seems almost incapable of achieving under other circumstances.

Implicit and tacit knowledge

Interpretation of information and comparing it with learned responses and experiential knowledge and bias is the essence of implicit and tacit knowledge. It is therefore critical, naturally that the information is interpreted in a fairly objective way if the resulting knowledge is to be accurate and reliable and good decisions made.

Take the situation where the project manager has been indoctrinated and reaffirmed again and again that the project is on schedule and will not fail, or will not slide and he has sent out the RAG reports and made reports and presentations to stakeholders and boards convincing them that everything is going well, how do you expect he will react to data, or information telling him that several key tasks have slipped and there are issues looming?

It’s all in state of mind

The fact is that if our project manage is part of the culture and one of the pack and he feels the pressure to make this project a success, he will convince himself so strongly of this that he will behave exactly like Festinger’s students did in his experiment back in 1957, he will fail to see, or assimilate that which contradicts what he has been told to believe by the peer group, that which is contradictory to the crowd consciousness.

The answer is simple

The project manager must be an independent consultant and he must be a facilitator only.
He must have no personal stake in the success or failure of the project in terms of hitting dates, amounts, or quality targets, but he must be someone who talks straight, keeps the “permies” honest, ignores the crowd pull and tells the Empror when he is wearing no clothes.

January 4, 2010

Putting agile in perspective.

Filed under: Systems, project management — Tags: , — admin @ 5:23 pm

This article discusses an important aspect of agile that is rarely figures in the big debate, i.e. where agile fits in the great scheme of things organiation wise. It also examines breifly  the concerns that are shared with general corporate activity.

It sheds light on  why agile came about and regularly returns to the fore only to disappear again and most of all it puts the whole cult aspect of agile under the microscope arriving at some perhaps unexpected conclusions.

Conclusion

Some people are overawed by the challenge of software development to the extent that they rely entirely  on a comforting framework to lean against, while others use their big picture perspective to manipulate the marketplace selling  their training, books and consultancy services under one disguise after another, while contributing little or nothing to the profession.

In reality there are two major challenges facing all software endeavours. The first of these is the challenge of dumning down science and motivating people to ahieve some sort of useful marriage. The scope is beyind this article but siffice to say that the internet arrived at least 25 years after it could have and is still years behind where it could be while people catch on to the possibilities. The antithesis of Moore’s Law  if you like.

The second challenge facing software projects could be summed up as defining an agreed goal and delivering on it.
in meeting that challenge the professional will follow the one very simple Software Development Lifecycle (SDLC) regardless of what methodology or framework he/she initially elected. That lifecycle can be loosely described as:

  1. Identifying the organisational goal the commitment, timeframe and budget.
  2.  Identifying a technical solution that meets that requirement within agreed constraints.
  3. Delivering the technical solution within agreed quality constraints.
  4. Delivering on the corporate goals.

The key to choosing and using methodology is to understand the challenges thrown up by a specific project and address them correctly. These challenges will be predominantly driven by corporate culture, process complexity, level of innovation, technical competence and budget constraints.

Ultimately it matters little whether you begin by creating detailed plans and evaluating them technically, or start building storyboards and prototypes. Likewise it matters not a jot whether you build it in time boxes, or spend two years coding before shipping the lot to outsourced testers, both of these approaches will have to meet all four objectives before the project is completed successfully.

There are however, certain projects that simply won’t fit a particular approach. One useful example is that you wouldn’t be advised to take an innovative prototyping and experimenting approach to air traffic control systems for example, as the consequences of error in the “trial and error “ paradigm are well known and best avoided.

The reason for the re-emergence of agile as an SDLC as opposed to a methodology is that it includes items one and four of our basic lifecycle in a single project.

Outside of Agile it is very rare for items one and four to be given very much more than lip service.  Business people are generally untrained and ill-equipped to rub shoulders with the technical aspects of this work and are understandably very frightened to make commitments and take responsibility for something they don’t understand and can’t control.  IT people are rarely equipped with the business knowledge and people skills to pull it off even if they were likely to be taken seruously by the busienss. Hence the ostrich syndrome prevails more often than not.

Agile breaks this deadlock by placing empowered people with all the skills they need and sufficient budget into a single team and telling them to make decisions and get on with it.

 

Agile is to the SDLC what a project is to the enterprise

“Agile places empowered people with all the skills they need and sufficient budget into a single team and tells them to make decisions and get on with it.”

Why does this statement seem radical to some people? Surely we have sufficient grasp of management in the 21st century that we can define a task and get it done with a level of motivation and commitment within just about any corporate body.  Well it seems not.

It is well documented and understood that once an organisation grows to the point where the founder can no longer be involved in every decision, there begins a phase that either destroys it, or morphs it into a modern political and mostly dysfunctional organisation that is driven by policies, processes and politics,  with little identity and few motivated individuals willing or able to chase opportunities or to excel.
The winning strategy to survive and prosper in this corporate world is based on being out of sight and below the parapets at all times except miraculously just after a victory and of course bringing apples to the teacher. Excellence is rarely sufficient and often unnoticed.
As these organisations grow within their specialised field, they substitute predictability, buying power and economies of scale for individual efficiency and innovation and they can survive and prosper despite the negative, but predictable performance levels produced by process heavy environments lacking in initiative, or motivation. 
The problems surface when you try to use that same team with the same culture to do something different.  Not only are you asking them to step out of their comfortable process, but a successful result will often bring with it an unwelcome and frightening change of culture for them and on top of this you are asking them to make decisions and use initiative.  All this in an environment which, through no fault of their own penalises initiative and chops off heads that protrude above the parapet.

This description may sound like a condemnation, but in truth it is just an acceptance of the fact that we are human and we adapt to our environment and that to achieve things we must begin with an honest, or even pessimistic appreciation of that environment and a plan to work within it.

Enter the Project

Although there are projects used in other environments such as construction where they are in fact part of operations, for the most part projects are used as frameworks for dealing with the issues described above. In fact, even when adapted to areas like construction, they still have a key role in abstracting the task at hand from the corporate cultures of client and supplier in order to progress the work at hand in a partnership or joint venture environment.
A typical project will create a governance structure modelled loosely on a company with a senior executive a PM and board that closely resemble the familiar frameworks of CEO, Chairman and board and operate in a similar way for course of the project. This structure releases them from the corporate culture and gives them the the framework and budget to get things done independently.  Just like real companies, they work well when the team are well chosen and pulling together and less so by degrees at other times. Projects without strong corporate support are up against it unless they have a very powerful and committed champion.

Why agile then?

Traditional Projects work well for large undertakings that are sufficiently in-your- face to gain and maintain interest in the boardroom right through to conclusion. Problems get solved and genuine mistakes are not allowed to become bargaining chips.

The trouble is that most projects don’t gain that kind of attention and are peripheral to busy directors and senior executives.  Board members are sometimes not ideally selected, not terribly committed, or even there purely to be kept informed. Occasionay they are hostile.  In these circumstances many projects lose their way for want of decisions, motivation, or intervention against blockers.

This is where the agile paradigm comes into its own.  Instead of creating this large and very formal structure that won’t actually gain critical mass, the key is to choose motivated, knowledgeable and competent people at the right level in the organisation, combine them with high quality technical and support teams and a skilled agile PM while completely empowering the team to make decisions and get the job done while providing access to a senior executive as and when required.

This agile approach returns the project to a small company paradigm with motivated, committed individuals operating with a shared vision, making decisions, communicating meaningfully, pulling together and getting the job done.

The software profession at its best

Surely we have taken software engineering to a point where a reasonably experienced engineer can decide whether something is achievable, give a time-frame and budget and stick reasonably close to it. Again it would seem to be a singularly difficult challenge for the profession.

Since the late fifties, the software industry has learned and developed along a predictable path that is in some ways remarkable and yet in others frustrating.  The return of the same old questions again and again is partly seen as the rejuvenation of boring old ideas for immediate financial gain and this view is not without any truth, but it is also part and parcel of how humans increase their knowledge.

Hegel described the increase of understanding in terms of: Thesis, antithesis ad hypotheses.

In effect he suggested that learning begins with theses, some of this is then rejected (antithesis) and finally, on reflection it emerges for use and further consideration (hypothesis).
Software engineering has developed at a rapid speed through borrowing from hardware engineering, construction and manufacturing, trying these concepts, improving them and trying again. Between 1950 and 2000 the average cost per line of code in use at the US Department of Defence dropped from $10 to $ .000001 as the industry matured. The industry has progressed rapidly in engineering terms, but there’s still a long way to go and especially in terms of interface with the users and investors.

Coding time estimates

In today’s software engineering environment (as opposed to a newly formed team of programmers at random company ltd) the time taken by programmers while programming is roughly as follows:

 timebreakdown coding

In fact as a good rule of thumb, it is widely accepted that when a programmer tells you how long a job will take,  you need to multiply that figure by somewhere between 6 and 11 depending on his/her track record.

If this software is to be of any use it must also be documented for the purpose of maintenance and for implementation, training and user support. In a less mature team these figures would be easily multiplied by anything up to a further five.

Communication time estimates

As you build a team the time for team and project communication begins to rise exponentially as the team size grows and if change is frequent it can reach as much as 50% of all effort with alarming speed.

Propensity for change

 

 The cost of changing requirements/features grows rapidly according to how late in the cycle the change occurs.  This change is mostly driven by omissions and errors at the design phase and design or programming errors further along the cycle. Controlling these changes is down to excellent stakeholder communicat

Impact of change in a software project

Impact of change in a software project

ion and rigorous design and verification procedures.

The preceding paragraphs highlight the very topmost concerns in the simplest possible way yet it is clear even from this short commentary that providing even reasonably accurate estimations is extremely challenging and is a whole team exercise.

It is also worth noting that of the four steps defined in our underlying SDLC, the software engineering discipline only covers numbers two and three.
 Responsibility for defining the business goals and their parameters as well as responsibility for implementing the system in order to capture those benefits remains an equally challenging proposition and lies entirely with the business.
In a product paradigm, the only difference is that product management must take responsibility for customer consultation and feature design.

Software Development Lifecycles (SDLC) are over prescriptive and misunderstood.

The many incarnations of SDLC will generally expand very quickly into a complex map of steps with interdependencies. With the best intentions, they attempt to tie the practitioner into a very prescriptive set of steps, but in doing so they remove the emphasis on common sense and good communications. For the sake of simplicity, when appraising a project, I tend to simplify the lifecycle to just four goals that can be carried out in any order that serves your specific project and revisited when necessary.  By taking this approach, you can apply it to Scrum, RAD, Agile or any waterfall flavour equally well.

  1. Identifying the organisational goal the commitment, timeframe and budget.
  2.  Identifying a technical solution that meets that goal within constraints
  3. Delivering the technical solution within agreed quality constraints.
  4. Delivering on the corporate goals.

In the best implementations, step one receives lip service in the “Feasibility” stage and step four is hardly ever taken into account. In the worst implementations two and three are poorly implemented with substandard testing and little documentation.

Step three regularly suffers from confusion between user and investor with the real end user rarely beimg engaged meaningfully.

It doesn’t have to be like this and it most certainly shouldn’t, but the reality is evident everywhere.

Agile variants are all created equal and simply marketing ploys

SCRUM, Agile and DSDM all tackle the business perspective and place it at the centre of the project lifecycle, they incorporate testing and UAT into the development process and they place emphasis on communication at all stages of the process. Scrum is seen to go a little further in considering the user, though the others don’t exclude it.

Regardless of which flavour you choose, you can tailor it precisely to your project’s needs and the idea that one flavour is better than another is almost to suggest that someone who can master software engineering needs to throw out his book and buy  a different one to add a little more emphasis on the customer etc.

Other concepts associated with Agile methods, such as working in teams of two and holding scrum meetings are all engineering technicques that owe no alegiances to any methodology and should be in everyone’s toolbox.

Can agile be scaled?

There is quite a bit being written recently about scaling agile. I have to be honest in saying that I have not read any of it and don’t have any plans to do so in the short term, but I have read comments from people I respect and it would seem according to their considered opinions to be predictably bandwagon in its nature i.e. a new opportunity for trainers and consultants to wrap something familiar in new clothes and sell it again.

Just as we discussed the small company culture and large company culture earlier in this article, the software project also changes in its nature when the team, or the complexity grows and it is inevitable that more layers of management have to be applied and more prescriptive processes implemented and before you know it you will have waterfall regardless of what you call it.

Large systems can and should be broken down into smaller ones and some, or even many of these can be developed using agile methods, but the overall project needs a more planned and less dynamic approach both from an organisational and an engineering perspective. There is no silver bullet and no  substitute for common sense and communication.

The answer is simple, follow the simple four stages and use whatever methodology makes it easiest to achieve each goal and you won’t go wrong.

November 6, 2009

Communication for project managers

Filed under: Organisational change, communication skills, management skills, project management, soft skills — Tags: , , , , , , , , , , , , , — admin @ 3:11 pm
Communication code scheme

Image via Wikipedia

Introduction to the series.

This series was inspired by the growing concerns expressed by project managers about the demands being placed on them to be communicators, ambassadors, PR experts and even Marketers as they attempt to deliver complex change projects into organisations, especially in the IT field but not exclusively. 
Whether you are moving 1000 people to a new location or asking them to stop doing things the way they do and trust you that a new system will work better, the challenge has been raised and if you are not equipped to meet it your project stands a poor chance of succeeding.

 About the author   
Before you even consider communication with any audience from one person to 100 million people, you need to first gain their respect and trust. If you don’t, why should they listen to you.
Just like you they are bombarded with messages all day every day and they only have time to listen to a choice few that come from trusted sources , that gain their attention and arouse their interest.
Gain  their respect.
Don’t assume that these people know who you are and respect your knowhow, or your authority as the case may be. If you are sent by the CEO, then tell them up front and try to get some demonstration of this from the CEO. If you are offering them expertise, then tell them about your skills and background so that they can judge it for themselves.

Gain their trust

Trust is the most important part of communication by a long shot. Respect and trust are related, but not the same. You can win respect through winning trust, but not necessarily the other way around.
If I am to interrupt my busy day to listen to what you have to say, I need to feel I can trust it.
The best way to win trust is to genuinely be interested and concerned about the other person or the audience. You can’t fake this, unless you have shared experiences and shared fears, hopes, or aspirations, then you will struggle to be convincing. Unless you already have this shared experience, then the simple and the only way to achieve it is to clear your mind of all preconceptions and start listening, start asking questions, questioning the answers and listening with every fibre.
The more you listen, the more you will learn. The strange thing about listening is that not only do you learn a lot, but you start to make a lot of friends effortlessly.

What  you are listening for 

First what you are not listening for, you are definitely not listening for hooks to  let you push your story down their necks. You should be listening to what they are saying at face value. You should also be listening for the unsaid things, the little gaps in the logic and the things left for you to imply. These latter are the things you need to question to make sure you get the truth. If you are a walkover and you get it wrong, you won’t win much respect.

Tip.
Be truthful. If you don’t agree say so. This way you will still find many that agree and others that make allowance, you might even learn something.  If you are false, you will be caught out and lose all credibility.

You are also listening for communication styles the way they express ideas, the vocabulary they use, any analogies they use when discussing the issues and the general attitudes that prevail in that audience to prepare you for how to word your communications. More about this later.

You are listening for differing groups in your audience, I.E different perspectives or different ways of framing the same thing. E.G. Board directors probably have a very different viewpoint on a shop floor issue than the blue collar workers do. Later you will need this knowledge when we come to segmentation.

You are also listening for their motivations, you want to know what would be the thing that would make them most enthusiastic and what would be least motivating to be able to offer to them.

You are also listening for indicators of who their influencers are, who else do they listen to and trust and why. It may be Unions, it may be certain newspapers or magazines, or a TV show. Knowing this will help you to communicate effectively with them.

Listening is a learned skill and only practice will perfect it, it ,may also be a bit of a change for som people, I promise you that if you will try it out for a week, with no motive other than to see what happens, you will never regret it.

 If you are not registered, Regisrer Now to download a free paper [download#1]
 

 

Reblog this post [with Zemanta]

October 23, 2009

The IT profession where are they when you need them most?

Filed under: Strategic thinking, project management — Tags: , , , — admin @ 7:04 pm

The background and the big debate.

There has been a lot of discussion lately from entirely different quarters and from across the globe that carry the same fundamental messages and I am struck by the opportunity to achieve something of value if only we can bring some of these ideas and people together.

I took part in a global discussion recently  involving almost thirty project managers around the world  about the nature of project management and why IT projects go wrong.  The insights and collective ideas were fascinating and thought provoking.  Parallel to this there has been similar conversation about the issues with the IT profession and it’s relationship with business. 
The BCS has re-launched in the UK amidst various noises that recognise these same problems.  World leaders are all appointing  IT Tsars and learning the buzzwords.  The US has the first highly IT enabled president and innovative ideas are beginning to gain some audience again.
Project failures, the reduced numbers of young people entering IT and the critical role of IT in the future of the world are hot topics just now and rightly so.
Against this backdrop, we have dedicated and enthusiastic IT professionals out of work in record numbers, many suffering extra hardships due  to the insecure, cyclical nature of their normal employment and to add insult to injury the IT projects that are continuing are often in jeopardy due to being managed by untrained people.

There are two sides to this.

The IT profession, must shoulder it’s share of the blame for these problems.  IT people at the top of their profession too often and in too large numbers come across as  anoraks.
Failure to take an interest in their customers and the needs of those customers has left them out of touch, in the basement, playing with their toys happily and hoping someone will figure out why they need one and come asking.  The anorak will then reluctantly part with his baby, offering no help in it’s adaption and seem to take pleasure when the new owner runs into trouble.
This lack of foresight and fortitude has not only alienated intelligent young people looking for a rewarding career and especially women, but it has left the door open for the “one eyed man in the land of the blind” (OMB).
The one eyed man is the customer turned geek, the game keeper turned poacher, the guy, or occasionally girl, who was sucked in out of necessity and now lords it over all. Equipped with a few buzzwords and firm grip on the board, he or she drives fiasco after fiasco , wastes million after billion and IT as a profession shoulders all of the blame for his ineptitude.

Business leaders too are culpable and deserve most of what they get.  A CEO who didn’t understand finance and didn’t have a CFO, or other equally trusted (and trained) adviser would be rightly ostracised and.
Nobody even questions this for a moment, yet CTOs and IT directors are the exception rather than the rule and outside of the IT industry itself, a CEO who understands technology is rare indeed.

The CEO who chooses a legal adviser because that adviser doesn’t have a legal vocabulary and therefore can be understood, would rightly end up answering criminal charges, but this is precisely the approach he/she takes to technology advisers. The results speak for themselves

Which catastrophes should have been avoided?

There are in particular three types of IT disaster that arise specifically from the inability of IT professionals and Board directors to engage meaningfully and share knowledge.
1. The gap filled by the  “OMB” who understands neither IT nor business, and is not accountable, having  IT as a convenient fall guy, results in business  failing to start the right projects and failing to deliver too many of those they do start, or the costs being far too high.
2. Clever networking and marketing by the big vendors offers the beleaguered executive a sense of security that she/he is receiving unassailable advice from this big brand.  Not very likely and not very affordable. This is a key driver of inappropriate IT  investments.
3. The IT profession is alienated and discredited further, de-motivated and demoted to the basement with a prestige level marginally above that enjoyed by the caretaker, they skulk and take occasional pleasure in the mistakes of their peers. After all it is human nature.

So we are all to blame, how can we make it better?

As individuals

As individual IT professionals we absolutely must concentrate our minds on solving problems and making improvements that customers want and will pay for.  Tinkering with technology is a great pastime for those with a passion and it leads to innovation and creativity, but in business, at work, we need well focused solutions, well understood and  well delivered.
Above all we must be conscious of our image and credibility, professionalism, helpfulness, a real interest in our business  as part of the team and a willingness to translate the jargon and to spread enlightenment.

As a profession

It is a young profession and in reality there is no GP of the IT profession there are many specialists, education and career development needs to provide this missing overview and interface to the world as the core skill.
We need to improve our collaborative skills to embrace business and recognise their leading role as the financiers and drivers, listen to their needs and grab their attention to enthuse them about the possibilities.

We need to open and lead a dialogue with business that earns and keeps the respect we crave and deserve and places our profession in the position of trusted advisers in and out of the boardroom and educators at every level.

We need new disciplines to fill the role of selecting, buying and implementing technology professionally as opposed to relying on lifecycles and frameworks designed to support  software development way back when and management frameworks designed  for a Public sector  environment alien to the commercial environment, both of which are hopelessly inadequate and inappropriate for the current needs of business and public sectors.

Business

The ultimate responsibility is yours and you know where the buck stops.  Alienating the IT profession has not delivered the goods. Encouraging ambitious young managers to stray into territory they don’t understand attracted by sizeable budgets is the worst kind of mistake, because you won’t even know what it is costing you since you have nothing to compare it to. Taking advice from suppliers about what you should invest in is really not clever and will not leave much of the value on your side of the fence.
Take your responsibility seriously and learn enough about IT to be able to take advice and take a key role in decisions.  Ask your IT people, organise briefings with them for the whole company.  Have them report regularly on new potential opportunities and technologies and learn to innovate together.
Develop trusted advisers in your boardroom and take IT seriously as an enabler and as a critical force for maintaining competitive edge and an opportunity for gaining advantage.  Don’t gamble with something so fundamental to your success.
Ask yourself this, what is the likelihood of Finance, HR, or even Ops discovering  a twenty percent competitive advantage for the business next year?  There’s only one place you can realistically expect that this might happen and you need to be awake and listening and at the front of that queue.

Concerned politicians

Provide more support and opportunities for innovation in business.  If innovation is done in a business setting it will tick all the other boxes and drive successful products. We need universities too and we need them staffed with people who have spent at least part of their professional lives delivering in a commercial environment.

Create the environment where IT people can learn more about business and business people about IT and showcase this within the public sector.
Nowhere is IT treated more poorly as a profession than in the public sector, leading to only a tiny number of well paid IT professionals being employed there in influential positions, but an army of transient day workers,  described as consultants, but rarely consulted  with neither status, nor very much influence.
Nowhere has more money been spent on so little, or more blame been passed on to the IT profession.
There lies  an enormous opportunity to bring IT in from the cold and put it at the forefront of Government.

Start doing business with innovative growing small and medium local technology businesses that can deliver value to the tax payer  without cutting corners, or taking our revenues abroad  and reduce the reliance on global monsters that outsource 90% of their operations, draining both wealth, opportunities and  skills away from the local workforce.

World leaders

In dealing with the overwhelming problems that face us as a  global family from Global warming, to receding supplies of carbon fuels and the collapse of the financial system and more poignantly our confidence in it, there are few rays of light on the horizon other than those that might be offered, or facilitated by technology and most specifically IT either as a solution or an enabler of that solution.

Put a small piece of the war chest aside to challenge technologists and  accelerate the race towards solutions that can reduce or eliminate our reliance on fossil fuels, help us to cope with global warming and prevent another global financial meltdown.
Place our faith and our investment in intelligent use of technology, for there lies the only likely source of our salvation.

October 10, 2009

Don’t forget about innovation

Filed under: feasibility study, product development, project management — Tags: , — admin @ 2:51 pm

The first part of any project involves defining  the problem, deciding where to look for the solution and how to proceed with the search and finally defining the solution, validating it and getting agreement from stakeholders.

Now the nature of Technology is such that few of us are aware of what is possible and even fewer are able to see the impacts of these suggested solutions over and above the promised outcome.

Not only are few of us equipped to access the best solutions, but even fewer are able to recognise when we have a problem.  In technology speak a problem is closer in meaning to a mathematics problem , it doesn’t necessarily cause that irritating pain that our marketing colleagues like to focus on.   

E.G.  Let’s say chief zongawonga is worried that with 19 more children due this spring, he won’t  be able to catch enough fish.  His bright young progeny identifies the problem and suggests metal arrow heads that are more effective and mean they can quickly make extra spears so everyone can join in. That represents a problem known and tackled.
However, Zongawonga doesn’t know that monofilament nets are cheaper than arrowheads and one child can feed the whole tribe with one net.  Until he becomes aware of the nets, he won’t know he has a problem, or until his wives start leaving for the easy life with his neighbour who doesn’t expect them to fish.

The process involved in definition of problems and solutions differs not at all from the age old problem of effectively searching a global mountain of unstructured content as described below.

First you have to arrive at some fundamental conclusions about the problem, the possible solutions and how and where to go looking. Consider this example and then have a read through the innovative solutions put forward by Zyra and see if you don’t begin to question the stuffy, stuck in the mud methods of innovation and improvement that have become embedded in most modern businesses.

 ”just what are you looking for, anyway?”

  •  A known needle in a known haystack
  • A known needle in an unknown haystack
  • An unknown needle in an unknown haystack
  • Any needle in a haystack
  • The sharpest needle in a haystack
  • Most of the sharpest needles in a haystack
  • All the needles in a haystack
  • Affirmation of no needles in the haystack
  • Things like needles in any haystack
  • Let me know whenever a new needle shows up
  • Where are the haystacks?
  • Needles, haystacks — whatever.

http://www.zyra.org.uk/needle-haystack.htm

 

The answers you give to the questions above will have a profound effect on how you approach the project, how you define success and your likelihood of succeeding.
Furthermore, whether you are in charge of developing  market leading products, or keeping your company  at the cutting edge, taking a little time out to consider these questions and address them  innovatively will take your performance to the next level.

October 3, 2009

Developing as a manager involves choosing between tips that are often polar opposites

Filed under: management skills, project management, soft skills — admin @ 12:20 pm

Let me explain:

 Polar opposites:

  1.  
    1.  Perseverance is imperative, only he who is willing to persevere in the face of adversity will achieve anything worthwhile
    2. The definition of madness is doing the same thing repeatedly and expecting a different result.

How do you decide whether are inspired or mad?

Who do you trust to tell you?

Do you really want to know?

 

My view:  Succeed and you are a genius, fail and you are mad, but whatever you do, do with style and passion.

   

    1. She who fails to plan plans to fail.
    2. She who is most flexible will always win through  in the end

Which is your weakness, planning to the nth degree and following your plan stubbornly at all costs, or playing it by ear, because you don’t have time for planning?

 

My view:  Planning is an essential skill, but every minute spent planning on the basis of untried assumptions, is a minute you could have spent either getting on with it, or testing the assumptions.

  

  1.  
    1. Keep your friends close and your enemies closer
    2. Build on strengths, not on weaknesses

Is everyone out to get you? Are you the guy who they pick on? Or do you find friends everywhere you go? Are you a soft touch? Or a ball breaker?

 

My view: It takes two to tango and that includes falling out. I recognise that sometimes you have to be wary, but it is better to play the ball than the man.  Keep it professional.  If you have an unpopular job to do, you can’t expect to be popular and most projects will adversely affect somebody’s comfort.
Focusing on the benefit, while not ignoring the casualties, or apologising for them either  maintains balance, while good planning and momentum will usually dissuade the objectors in the end.

 

  1.  
    1. Vision is the quality that makes great managers
    2. Attention to detail is the mark of a true professional

Do you live in the high trees, or do you spend your time grubbing about in the undergrowth.  Are you the guy who can’t wait to run a spell check, o r are you forever re-reading and improving till you rarely go home before seven and you are always behind?

 

My view:  The real skill  lies in the ability to Chunk up and chunk down in your thinking. It is a learned skill that takes discipline, but you have to know when to climb a tree and get a better view and when to crawl carefully through the undergrowth.  Most imprtantly you need an instinct for “Fit for purpose”

July 2, 2009

Planning for project managers.

Filed under: Systems, management skills, product development, project management — Tags: , , — admin @ 2:40 pm

How important is planning?

Planning is critical. Without planning there is little chance that you can every complete your project, let alone complete it on time.

 The act of preparing a plan, if done correctly, will uncover the issues and risks, provide the bulk of key data for your estimation efforts, provide a clear view of what resource is needed when and lots more.

 It will also help to discover the dependencies that may exist with other projects and activities.
Once prepared, the plan gives the team a better view of how their efforts will come together and points out the need for communication in critical areas.

 

How important is the plan?

Much less important than the act of planning, but still very important. The reason I say this, is because:

1)  It is rare to be able to complete a first draft plan and then not have to make any adjustments.
Most plans develop as they go along and reach a baseline when well into the project timeline.
The most obvious examples of this are projects that involve investigating a problem designing a solution and then finding suppliers to deliver it.
You can allow extra time at the start in the hope that it is definitely too much , but even then, the chances are that you will end up adjusting your plan.

2) Risks and opportunities are a part of every project plan. Sometimes risks come to fruition and they affect the plan profoundly, sometimes opportunities come along that are either too good to miss and causes change of requirements, or  reveal a cheaper, or faster way to get it completed.

In either case, the initial plan will have changed. To live in denial of this as many commentators on project management still do, is a huge mistake and will always be counterproductive.

E.G. If you become so obsessed with meeting a specific date that you are prepared to pare away key features, there is a strong likelihood that the project will fail entirely. The answer is to treat the plan as a guideline and treat planning as an ongoing task.

I recently had this same discussion with a group of seasoned Venture Capitalists and their view was this: 
They would never dream of setting out without a plan, but once they had it in place, they may as well tear it up, because it had already delivered most of it’s value and form here on in, it was more about managing the risks and spotting the opportunities.
They were unanimous in the view that to slavishly stick to that plan would be suicide virtually every time.

Starting a new venture is much more volatile than starting a project, but it is also higher pressure with greater risks and a lot more to lose.  They don’t actually tear up the plan of course, they adjust it and maintain it, but the discussion served to get their point across that management is about managing and adapting on a daily basis, not stubbornly following a plan regardless.
Managing a project should be driven by the business case in the same way that a new venture is driven by reaching a profitable trading position at some point.

Critical also is the acceptance that like a start-up, many good projects are based on a strong hunch and a bit of a gamble for a wothwhile prize. This is enterprise nd without there would be no paydays.  project managers haven’t earned indemnity from this either. 

Features – Deadlines -Budgets – ROI

Here’s where it all happens.  A project will have a goal and that goal will usually be a financial one though success is not always measured in financial terms.
For the sake of this example I will assume that the project is a cost cutting exercise with a specific financial aim. Right at the beginning, the same ground rules should have been laid down such as;

  • What saving are we aiming for?  
  • What investment are we willing to make?
  • What is the maximum our budget can rise to, or the minimum our savings can drop to.?

This latter question is best answered in terms of ROI and in fact, in most commercial organisations the answer will be worked out on the basis of how much ROI exceeds  ”Cost of Capital” in order to qualify the project as “best use of capital”. The critical thing is that it is agreed in advanced and set up as he target.

Once this understanding is in place and the variances have been explored and allowed for, the business case should clearly show the expected returns and the tolerances that are allowable.

The project now has an ambitious goal (maximum realistic returns) and realistic allowable variances. The importance of these variances is not to make the project management team relax, but to assure the sponsors that their investment is relatively safe. Projects set up this way rarely fail.

MSF, the Microsoft flavour of project management introduces a very useful concept known as the project triangle. It is a simple triangle with the three corners being occupied by Features – Resources – Time.project triangle

The significance of the triangle will be obvious to any mathematicians reading in that only one corner of a triangle can be fixed unless you want all three to be immovable.
This is why the prioritisation of concerns is a valuable part of stakeholder alignment. If stakeholders are allowed to follow their natural instincts and demand that all three corners are fixed (two fixed corners means the same thing) then there is no room for the project management team to steer the project out of trouble.

A realistically aligned project will choose one of  Time, Features or Resources to set in stone and the other two will remain free to move.  This way, if time is fixed, then a PM can choose between increasing resources, or decreasing features in order to hit the target (ROI). The decision making process can also be agreed in advance.

This example is one of the simpler ones, but it is indicative of the ills that beset many projects right at the beginning and rob them of any real chance of succeeding, or being seen to succeed.

Defining the scope/budget/resources

Once again, with the ROI in mind and the statement in the business case that based on initial studies, there is a strong likelihood of success, the task now arises to define in more detail the features required to deliver the expected benefits.

Having defined the features, accurate costing has to be worked out on the basis of supplier estimates, internal efforts and other costs, with adjustments for risk, all of which will rely on your emerging plan.
 Another sanity check at the end of this planning phase should check whether  the cost and time estimates are still within the constraints initially set for the project and whether it has a healthy amount of slack remaining to see it through to a likely successful completion.

This exercise of working up plans from draft to more detail as the work progresses from an outline business case through to a detailed contract with suppliers and a detailed plan of implementation with all the appropriate slack allowances  and a rigorous risk assessment will often take up half of the lifecycle of the project, or even more and some projects will be abandoned when it becomes obvious that there is little likelihood of success.

 The number of “stage gates” (sanity checks) should be agreed at the start on the basis of how well known the territory is and how volatile the estimation is likely to be.

The illusion that a project board can put some dates (when we’d like it done) and amounts(how much we’d like to spend) on an A4 sheet at the beginning of the exercise and that perhaps a year or more later, a project team will deliver exactly what was asked for on that sheet, within exactly that amount and on that date is really a surprising error of judgement, but it still happens and contributes strongly to the list of project failures that appear on the Standish report and other investigations.

 

How to go about project planning

Planning should always be done by starting at a very high and general level, involving experienced big picture thinkers and applying a sanity check before then drilling down not too far to the next level  detaiil to repeat the exercise.
Planning should always resist the temptation to go into great depth in one specific area while remaining at a high level on others with one exception.

If there are unknowns, e.g new concepts that might not work, then proof of concept should be carried out as soon as possible to avoid having to abandon the project or change tack after a great deal of money gas already been spent

 

Plans should not be in extreme detail a long way in advance, because the likelihood is that when that time draws closer you will find yourself redrawing them and the effort has been wasted.  As planning continues to drill down, a plan should be retained for each level of detail and when the detail highlights an error in the high level plan, as it frequently will, then the high level plan should be adjusted.

 

The commonest method of estimation to begin with is to break the project down into products.
These products can in turn be broken down further until they reach a level whereby they can be more easily estimated and planned and later assigned to teams.

Out of this comes a product flow diagram that describes the order , if any, in which these products must be completed in order to take account of interdependencies.

Calculating critical paths ( the longest path you can follow) through the products and then amongst the products, the project manager can get a much closer view of the true schedule of the project.

Using PERT to make a high level allowance for uncertainty adds a further level of sanity check to the emerging plan.

Some of the issues that commonly affect project plans drawn by the unwary include :

1. The calendar is not taken into account when calculating for tasks in the plan, e.g seasonal breaks, Summer holidays and other disruptions that happen every year.  Key personnel  disappear and dependencies become critical.
Make sure you discuss each team members responsibilities and schedule with them and get agreements.

2. Suppliers work to their own schedules and regardless of what they agree,  they will place commercial concerns first and may not follow your plan.
Ask them for their plan and question to satisfy yourself that it is thought through. If you  lead, or take part in the contract negotiations, try to place some extra responsibility on them to deliver on time, or warn you in advance.

3. Estimates from technical people are accepted at face value and in reality they are vastly underestimated 80% of the time.
Get second and third opinions, look at records of old projects and as a minimum double the estimates from the best people and use factors as high as five for others.

4.  There’s gaps between what the supplier delivers and what the internal team have allowed for.
e.g. Inexperienced people might assume that a system can arrive, be plugged in and start testing.
Clear acceptance criteria may not exist and there may be problems agreeing acceptance.
Cut over from an old system to a new one may not be catered for.
 This list can grow quickly. If you are not an experienced systems person make sure that there is one in charge of this part of the plan.

5. There may be several suppliers and communication between them may be less than ideal. Often this situation leads to gaps where nobody is responsible and the work grinds to a halt, or even enters dispute , or litigation.

Make sure you hold joint planning meetings and get sign-off to theses joint plans

6. Beware Johari’s window. What you don’t know you know is a terrible waste, so consult and consult again. What you don’t know you don’t know will come back to haunt you, so involve everybody in risk management sessions and try to be ahead of the game, have sufficient slack and keep stakeholders informed of the true position.

7. Over ambitious, or over confident plans create a sense of expectation amongst stakeholders that changes to discontent when the plan slips. Perfectly good projects are often deemed poor projects as a result of this very mistake.

Take the time to estimate risk realistically and maintain realistic slack for the high risk areas of the project.

 

So in summary:

1. Planning is critical and underpins everything, but it is an ongoing everyday task, not a game of snakes and ladders.

2. Managing projects is primarily about handling and working with uncertainty to remain within agreed, acceptable boundaries, not shooting a silver bullet at a precise point.

3. Planning for well known items is easy, beware what you don’t know, this is where you will get caught out.

4. Risk and opportunity go hand in hand, avoiding risk is no more important than spotting opportunity , but it requires an open mind and a fluid approach to planning.

5. Start with an achievable goal, make sure it is well understood and shared  and keep it in front of mind at all times.

June 16, 2009

Programmes are the reason so many projects are deemed to have failed.

Filed under: management skills, product development, project management — Tags: , , , — admin @ 12:28 pm

Build a dungheap and the insects will come

I just left a meeting where we discussed a large and complex programme of work and my mind kept going back to recent discussions about why projects fail. We have been talking about project managers who stay in the office playing with gantts and charts and PMs who know nothing about their subject matter, but see themselves as traffic coordinators. These are real concerns and they are at epidemic level at least and need to be discussed and resolved.

Take one step back from this discussion,however and place yourself in the average programme office.

If the Project manager rarely sees the battlefield, and spends his time constructing fantasy plans without ever checking with reality and assuming that things will stay the same, then imagine how far removed the average programme manager is.
Today I watched just such a Programme manager going through a programme plan and showing the position of each project and of each tranche and giving a thoroughly convincing performance, but based on a few conversations with project managers before I went in, things were not at all like the programme manager’s presentation suggested. Not only was he highly removed from the truth about the various projects, the truth of which was obscured behind vague and even pointless KPIs, but he had no idea of the true situation within any of these projects. One project had reached it’s milestone just ahead of the presentation by launching something totally flawed in the knowledge that it would not be found out for a while and if they hadn’t fixed it in the meantime they would deal with it then and feign ignorance of it. The KPI was declaring completion, not passing though any realistic test of completion.

How can you risk manage a programme without total honesty and a powerful beam of light?

I dread to think of the consequences for his programme of a key project on the critical path getting into serious trouble. If he is measuring the programme with this type of metrics and this lack of control, what chance is there of coming anywhere close to success?
As it happens that project is a critical one and it can stop the entire programme., it should be the focus of major attention until it is out of trouble or the whole thing is abandoned.

There is no difference between this handling of projects and programmes and the commercial practices of reporting false profits to keep shareholders happy and  keep the capital flowing your way.  We have created the conditions for failure and it will continue to happen regularly just as a pile of compost left in the garden will attract plant life.
Is there a realistic answer on either front? I will have to think about this one.

One note in my notebook is quite revealing, no member of the board was present to learn how things were going.

 

 

June 13, 2009

Agile Agile the rumblings continue. .

Filed under: Requirements, product development, project management — Tags: , — admin @ 9:12 am

Had another heated discussion with a self professed agile Guru who declined the offer to take the conversation public and place his arguments here, so I will do it on his behalf, but allow him the anonymity he desires. I will refer to him as John for argument’s sake and leave out some of the less important stuff.

The argument went like this:

John:  Your perception of agile is not right, you just don’t see the real benefits of agile because you are not a true agile practitioner, you just use it as a looser form waterfall when it suits you, but you never really took the faith. We are delivering year in and year out in a way we never could with a traditional approach.

Ed: I’m inclined to take that as a compliment. I hold deep suspicion of anyone who takes a methodology too seriously above and beyond the actual delivery of an end. I have indeed used agile to great effect, but wouldn’t use it except in situations where I believe it is the better approach.

John: That’s just it, you believe you know better, but if you tried it in this other situations you would find , like we do that it delivers more every time.

Ed: I would be interested to see the definition of delivers for the sake of comparison. I won’t discount the possibility that you are right, because like you, I don’t have facts and figures with which to make a real argument, but I do have compelling reasons for my decisions that I am happy to share with you.

John: And they are. .

Ed: 

1. Given and ideal world, the shortest and cheapest way to an end result in software is to know exactly what you want to achieve in advance, then know exactly what how is best to deliver it via software, have experienced people to do it, test rigorously against your acceptance criteria and roll out it once working perfectly.   I doubt anyone would argue with that.  I do accept that it probably has never happened and possibly never will, but it is the perfect scenario.
If we both started together and you used agile while I used a waterfall cycle, there’s little doubt that I would finish first and come in cheaper, though given the smoothness of the task, you would also perform well.

I would expect in that scenario, to get the business design right first time and agreed, to get the system design right first time and to have a very low level of defects in testing and instant acceptance by the client. Your trial and error approach would waste precious time and produce unnecessary artifacts.

 

2. The reason a business and I include in this definition the majority of public bodies, invests in IT is to save money or earn money. A commercial operation needs a return higher than the cost of capital as a fundamental criteria and it must also qualify as best use of limited capital.

The toughest part of a business case is nailing down the cost. If you don’t know the cost with a level of confidence, you can’t estimate the return confidently and you don’t have a case.

The agile argument about  “fit for purpose at  maximum cost” works well provided “fit for purpose can be relied on to deliver the expected returns and assuming that  it can be achieved, but ultimately, unless you can define the requirement well enough in advance to estimate the cost within reasonable boundaries and prove a business case, you are unlikely to ever get off the ground and probably should not.

 

John:

I don’t believe there would be a great deal of difference between the two performances is that case.

Anyhow, that’s all well and good, but there are many other scenarios where the business case is proven by the do nothing scenario alone E.G. defence, environment etc where the costs cannot be calculated accurately, but there is no argument about whether it should be done other than to figure out what will work best.

Ed: I agree with this entirely and in any of these many situations, I too would use an agile approach to remove the likelihood of a colossal error by learning as we go along.

It went on further but the point has already been made

This conversation went on a little longer and covered more ground, but I do feel that a lot was revealed about the importance of using the right approach for the right situation.

I do believe that a good business analyst with strong consulting skills can still earn his keep time and again by getting the requirements defined , understood , tested, verified and agreed at the outset so that accurate costing and planning can occur and the most cost efficient route can be taken.

I often see an agile approach taken as a substitute for consulting skills rather than as a good strategic decision and I do believe that this does nobody any favours least of all the agile approach itself.

About the author

What every business should know about agile

When is a business case not a business case

Agile- is this a short lived fad?

June 10, 2009

The true DNA of an agile project (exploding the myths)

Filed under: Requirements, Systems, product development, project management — Tags: , , — admin @ 8:38 pm

Ignore the new vocabulary and you’ll find nothing new in the concepts.

If you have heard me pour scorn over some of the claims made for agile, you may be surprised to know that I’m an agile practitioner with some considerable experience and not at all adverse to the approach.  That said, I always repeat the words of my agile mentor Keith Richards (no not him silly) when I asked the obvious silly question. He said ” It’s horses for courses.  When you turn up for training we assume a certain level of education, intelligence and experience”.

OK so what is the big noise about. Well the underlying promise of agile emerged back in the seventies soon after the first Standish report when some of the industry leaders cooked up an alternative to the waterfall way of wasting money.
The theory and indeed the practice is totally valid when followed with a level of honesty.  You tell me how much you can spend, or how long you have and I’ll guarantee you a working system.
Note the difference from waterfall where you have two options: fix both budget and time and have a failure nine times out of ten, or fix  just one and reduce the odds by 2/3.(MSF).

Agile delivers on the promise when billed honestly and executed  honestly.
Here’s the metaphor.  Say you meet with your co-directors and agree that right now the thing that will  accelerate you to your goals is an very large extra table  in the boardroom with a tiny door and spiral staircase and you have only £n  to spend, or n months to deliver it. I will discuss your needs at length, then I will come back with a proposal that looks like this.

The minimum required to make this work is a top and thee legs. You don’t need four to make a table work, though I agree it would be nice.  It can’t be bought and even the top has to be constructed on site.
The legs are standard things and fundamental so I will order three of these and have them delivered.
We will start making prototypes using scrap wood  for legs and sticking planks together until we have a table that is just stable enough and functional enough to meet your needs.

This we are confident we can achieve within your constraints, if we have extra time or budget, which I expect we will have, we can add a fourth leg, or smooth it over, or add a coat of varnish. You can decide when the time comes, which is more important. That’s it. No miracles, no free lunches, just less pontification, more action and a product that is fit for purpose, if not always entirely pretty.

 When you wouldn’t use agile.

You would never use it to build a space shuttle. That type of project requires a right first time approach.  I shouldn’t joke about a tragedy like that. There can never be a serious consequence of getting it wrong first time. You shouldn’t use it unless you are bought in fully to the three legged table, if your mind is set on four, stick to what you know. If you are buying in the team either as contractors or a service company, it is risky, because highly competent  people is a prerequisite.
If your main motivation is to be involved on a day to day basis as opposed to making a decision up front. It is poison, keep away.

Older Posts »

Powered by WordPress