Some serious questions for anyone considering Cloud investment

On Feb 26th posted a piece in which I warned readers of the dangers of buying into CLOUD solutions without due care and without attention to all the little details they would pick through if they bought a small solution from me or even from an SME or “front of mind “,  big noisy solution provider. On March 1st 2017, Amazon went down to the shock and horror of the media at large. I promise you I had nothing to do with it, but I did get a flood of emails, some of them quite amusing.

Cloud services
Is the cloud right for me

The HIC problem

No I am not referring to the HICKs of Hicksville but rather to the much more common problem of “Hiding in Crowds”.  Closely related to the brand new evil you hear quoted everywhere, “ Populism”.
A populist is someone who, seeing his sweetheart taking a dip on the next plain, pretends to hear a lion and quickly convinces the herd to rush over there.

The HIC theory is sound enough for a plain dweller, if you are part of a large crowd the probability of being the one chosen for lunch by a marauder is very low, especially if you are careful not to stand out, I.E. don’t say or do anything different from the crowd.
If you are responsible for making key decisions on a modern organisation you can also retain some credibility after a disaster by saying , “Well everyone believed this at the time”,  or ” look at all the others who fell for it”.
If you are a responsible individual or if this is your own money at risk then you simply can’t afford to be a HIC.   What that means is making your own decisions on the basis of information, accepting the risks you can’t control and standing by your decisions, while always being open to new information and constantly monitoring your sources. E.G. You need to know who his sweetheart is.
Here are some thoughts to help anyone struggling with these decisions.

Business case for cloud investment
Building a business case for cloud investment

 

Some very strong arguments for investing in a cloud solution

  1. The IT department don’t want to give me a “NDB system” because it can’t be justified financially and won’t fit into the Enterprise Architecture just now. Who do they think they are, I’ll rent a cloud solution and I won’t even need to tell them let alone ask. That’s not as dumb as some might think. There are plenty of situations where this will be a good answer, just be sure that it is a temporary and not a long-term part of the business strategy and be absolutely clear that a: data is handled strictly within the law and b: You can get your data out safely when you need to and get it into another system. Remember you are responsible, not the cloud provider.
  2. I have no or an inadequate IT department and don’t want one because I won’t be able to control it. Instead I’ll get this cloud provider to give me the whole thing in one go and the problem is solved. You have to love it don’t you! If you truly do find the right solution available via this kind of deal that’s a big part of the problem solved, though by no means all of it. You are going to need a hell of lot of skilled man hours by some smart IT guys to arrive at that conclusion though and it will still be a best guess, just a very much better one.
  3. I don’t have and can’t or won’t raise the capital needed for this huge system I want, so I am going to rent it from a cloud provider and keep my capital working at the coal face. Not bad thinking on the face of it. Do consider the following: Are you really in business with insufficient access to capital to fund core process? I doubt it. Do you seriously make decisions about employment of capital in this way? Do you have a business case? If it says this is a good option, then given all the other ducks are in the right places, what are you waiting for?
  4. My business is made up of the original business plus a growing number of acquisitions around the globe, I am fed up of struggling with 7 different CRM systems and all the others, I want all of it in one system so nobody tells me again that the revenue from selling “tap”s was missed because 30% of sales were classified as “Faucets” and all the myriad of other such errors that turn my reports and dashboards into danger zones rather than information.
  5. I need my people around all of the group businesses working together to innovate and share ideas, but it is hard to achieve when they are working with so many different systems and using different vocabularies to discuss essentially the same thing. I want to migrate all of these businesses to cloud systems and administer them from Group Head Office, then we will be one business instead of 75
  6. I have fairly good systems and I am reasonably satisfied with what I have, but I need the ability to handle large demand spikes better and I need to prepare for an increase in the regularity and size of these spikes. Buying hardware to deal with this could be very costly and offer a low return on investment, given it would be redundant most of the time. I plan to extend my systems to encompass a cloud element so I can rapidly respond t short-term sever spikes in demand.

Some “gotchas” you really need to keep in mind

1 I need my CRM/ERP/other to be available via browser from anywhere in the world.
That is not cloud, that is Worldwide Web. It’s been around since the early 90s. You don’t need a cloud discussion, you need a web hosting provider and someone to find you a good free open source tool. If you don’t believe me, I have done tis more than once.

  1. My industry is highly regulated, e.g Pharma, Finance etc I need to bear this in mind.
    My personal experience of this is based on Pharma, but I believe the principles are the same.
    Right now there is a fledgling process for validating public clouds as suitable for specific types of data and sometimes or specific situations and geographies. Being a very new industry and a not well understood problem domain, the regulation is immature and almost certainly inadequate. If I were making a decision for the medium term, I’d be very slow to risk the future on what we know today and I certainly wouldn’t expose myself to any assumption that today’s regulation would be sufficient for tomorrow. Handle with extreme caution or stay way entirely is my personal view and that is based on knowing what we don’t know rather than any certainty.
  2. My business needs to be operating every day with no exceptions. Outbreak of war, epidemic you name it, this are more likely to be opportunities , or maybe the scenario is that I have a legal obligation to be operating. If this is you, don’t so it.
    a. Using the cloud depends on the internet and increasingly on mobile phone signals. This is still an area for very mixed quality of availability and signal across most of the globe, but do bear in mind that Governments everywhere hold an off switch for the mobile phone network and internet, any kind of political crisis can at any time lead to a black out in one or many regions. Can you handle that?
    a.i. The internet is not nearly as robust as people would have you believe. There are many points of failure and they are sought out and taken down from time to time. Logically, with all the publicity from the US election, this kind of thing will become more and more popular. Recently DYN the people who help with dynamic DNS issues were taken down bring the whole East Coast of Americas TV entertainment to a virtual halt and costing people like Amazon, Netflix and others fortunes in lost revenue. Expect more of this leading to more of above.

A.ii. Large providers such as Netflix for example are heavily exceeding their peering agreements or downstream traffic with the result that they are being throttled. This makes viewing almost impossible for many customers.  Such throttling is perfectly legal and it is likely to be used as part of trade wars between rivals. Your business could easily become the innocent casualty in one of these battles.

  1. Since my days in the broadcast industry I remember the affect Netflix had on the Amazon cloud when they were busy processing film. It was a well-known phenomenon and it lead my client of that time away from that solution. There has been a catalogue of large outages on a fairly regular basis since the beginning of the cloud movement and I fail to understand why somehow, senior CIOs clearly began to conclude that AWS and others were “Too Big To Fail”. Well that is reserved for bankers. The cloud can and will fail. It is technology and politicians don’t have much of value hidden there, so don’t be foolish about this.
  2. If the “Too Big To Fail” cloud provider fails, or decides this is no longer profitable, I must be able to replicate all of these services and carry on in business.
    Here is a simple piece of advice that I am grateful for having received a number of years ago.
    “Nobody sits around dreaming up risks that could not happen and writing complex legal clauses to extricate them form the risk situation when it occurs.” Let me translate that into simpler English; Read the legal contract, if the terms of the contract render the cloud provider blameless in such a situation, then they believe there is a really good chance it might happen and they know more about it than you do.

Unless you can build and rehearse a viable strategy for recovery given the reality of what might happen, you probably should stay away.

  1. Even if it were feasible, I wouldn’t put my entire business into a single cloud ERP and expect to live happily ever after, I need to be able integrate my systems in order that my people have efficient processes and data is not re-keyed repeatedly and I have an “almost trustworthy” view of the business to support decisions.

This is an area I have struggled with many times over a number of years and I can add to that the experience with non-cloud but WWW systems before that.   I have had a close and personal look at a number of leading cloud solutions and the variation in the quality of APIs provided is quite remarkable. One or two provided very consistent a comprehensive APIs, but the majority simply paid lip service the idea.
Even when integrating one of the better ones with systems “back at the ranch” we constantly ran into dead-ends where something we wanted, simply could not be done.
No is not a word I have ever accepted at face value and in the world of technology my first reaction always is, yes it can be done, even if we have to invent it. When your data is locked in a cloud data store that sometimes even the operator can’t understand with certainty and more to the point, you are not allowed any access to it, then it is beyond your reach unless the API provides access. Hence, “No API, no Data” Any architect will tell you to avoid going direct to the data store and I agree totally, but once in a while when the goals is big enough and there is no other way, it saves the day. Not with cloud services, unless of course you are referring to your own service built on PAAS or IAAS, see below. That is a different scenario and outside today’s scope.

               

 

Some definitions and buzzwords you need to keep an eye on

There are so many experts out there and so many levels of depth different people want that I hesitated to add this, but hopefully this will help some users. If you need deeper explanations google will find you more than you bargained for.

Cloud.  It began with the little cloud icons used to denote internet, and now it seems to have settled as any system you access via the internet rather than on you own infrastructure.  There is always an exception and this case it is the cloud you build on your infrastructure, see the next item and don’t get too hung up on this.

Private cloud.  This is about using the idea and the tools of the cloud to build a central resource on your own infrastructure.  The benefits are for example ability to virtualise servers of any size for a specific task  thus offering tremendous flexibility and potential savings, though licensing systems in cloud is a hugely complex area and a real minefield for assumptions about future costs.

Hybrid cloud This is simply a combination of the two above joined virtually to provide a single network so that the public part of your cloud appears and functions in almost every way like it were your local private cloud.  This gives tremendous flexibility with an ability to rapidly scale for sudden changes and reduces complexity at least at a superficial level.

 

PAAS.  This is really just the cloud providers renting you out the systems on which they build their applications. It is very similar in ways to renting virtual servers from a hosting organisation and building your application on that. The same principles apply. It saves a lot of time and capital investment and is especially useful when you want the ability to fail cheaply with something.

 

 IAAS.  This is as PAAS except that they are only renting you the infrastructure .
Within this are some very useful services that provide an end to end Continuous integration pipeline ready to log in and start developing software.  This is hugely valuable to software business not just impacting cost but also quality and consistency.

 

Don’t forget about innovation

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.

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

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.

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

What would you like sir?

Countless reports on the reasons for project failures in the software industry point heavily towards poor requirements as a source of the problem. It isn’t too hard to see why that might be. After all if you hope to get exactly what you want, you are going to have to spell it out in some detail.

How many times have all of us left a restaurant disappointed because we misinterpreted what a dish consisted of, or had a bad experience ?

Ordering what you want in a restaurant where they speak your language is relatively low risk. There is a risk of misinterpretation and there is a risk of a poorly executed dish, a meal that arrives after a very long wait, or a nuisance at the next table making you uncomfortable.

If you want to give yourself a strong chance of being satisfied with your meal, first you will need to be aware of all these contributors and make your choices with this in mind.
Taking this approach might help you avoid the family from hell at the next table, the dish that isn’t what you expected etc and if it doesn’t work out you are at least in a strong position to seek recompense.

Software is much more complex than food and like a restaurant meal there are more concerns than simply  the ingredients. In an ideal world you would be dealing with a professional who could interpret your tastes, avoid the poorer restaurants and order on your behalf.
This is the main purpose of the Business analysis and product  development body of knowledge.

It gives you the option of working with trusted professionals that can help you achieve what you had hoped for and keep your costs down.

Product versus System.

Few people stop to consider the difference between developing products and developing systems for a private audience and will often approach both in exactly the same way, but although there is a lot in common, there are also critical differences.
1. The first and most important difference is the fact that a system will be rolled out to desktops ot devices and the organisation will train users and tell them to get on with it, whereas a product will be launched into a marketplace who have to be attracted to explore the product and then persuaded to purchase it.

  1. A system will largely be rolled out into a controlled technical environment whereas a product will be at the mercy every conceivable version of operating system and technical environment.

  2. A product must breakeven quickly, deliver a profit in the long tail and exit gracefully before it becomes a liability.

The first of these is one of the more telling differences for our purposes because it requires an entirely different approach to understanding requirements  and defining outcomes and it introduces a whole new level of financial constraints.

When developing a product, the Analyst/Product manager  is often working with a user advocate  or product forum to define the desired functionality and get requirements down on paper in the same way as with a system.

A better process will run Alpha and Beta releases with early adapters in order to learn about how users react to it and make critical changes that improve it’s chances. In an Agile world the Product Owner will release an MVP (Minimum Viable Product) and perhaps then an MMP (Marketable)
All the time the success or failure of a product rests on the likelihood of the user base receiving it will, perceiving a persuasive benefit and viewing it as value for money.
The project manager delivering a system on the other hand has the luxury of rolling out a system and only worrying about complaints that threaten it’s ability to deliver.

The project manager can learn a lot from the product manager in terms of delivering a well received output and maintaining good communications with stakeholders.

Innovation as opposed to state of the art

Projects that involve a level of innovation either in terms of process or the technology to drive it will require a different approach and a strong element of prototyping both as proof of concept and as a way of communicating to users a blue skies concept, will generally be the better approach leading to a point where requirements and scope can be nailed down and the process of delivering it can get under way.

Complex domain knowledge

Another situation requiring a different approach to requirements is the one that involves extreme complexity in a domain outside the scope of the analysts, project managers or technical staff.

Let’s say for example that we are building software to manage extremely complex trend analysis for  forex traders and only a small number of skilled individuals understand the underlying mathematics.

To get a product manger or analyst to a sufficient level of understanding could take years and it would still be a second best option. The best option is a totally agile approach whereby the statistician the analyst and the developer all sit together and build prototypes without the statistician ever needing to understand the underlying code and architecture, or the programmers and analyst ever understanding the fine detail of Monte Carlo analyses etc being used to construct models.
In this situation the requirements are written after the code has been written and unit tested and it’s purpose is to support maintenance and future development processes.

COTS versus Development

The biggest area of effort by a long shot is the purchase and implementation of COTS (Commercial Off The Shelf) software systems.

Right form early days in the industry, there was a realisation of the need for reuse of software and many of the various efforts that came and went have been sold to us on the basis of promoting re-use. In reality precious little is developed in Com or reusable classes and SOA is still not that widely used.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never caught on, but COTS systems did and today there is very little development of end to end systems outside of software houses that develop products.  Nobody builds their own CRM, or ERP, etc, because it makes no sense when you can buy it straight out of the box at a fraction of the cost. Bill Gates freely admits that he ran the business on SAP using his own products to integrate where he needed the extra flexibility.

The issues with COTS however are that businesses are all keen to differentiate their offerings and this adds to the variety of processes and business models in operation which in turn means that many of these all encompassing systems are a compromise rather than a solution and require a lot of integration and customisation in order to make them deliver benefits.

There has never been to my knowledge, any attention given to the needs of these systems. The most common problem I have encountered is people from the business assuming that you don’t need the normal skills to deal with this because it is in the box and it is like buying a lawnmower,  you bring it home and tell “the IT boys” to plug it in.

In reality this is a very dangerous mistake and pitfalls are as follows:

  • You are reading wooly,  warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS is sold with a “Caveat Emptor” clause and unless somebody knows all the details of what it must do and whether it actually does, then you will end up with a very expensive system that just is not suitable.
  • The complexity and risk attached to integrating COTS systems with other systems can sometimes make them almost as expensive as starting form scratch.
  • The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood.

The job of procuring COTS software is  complex and tricky and it can often be a struggle to convince business stakeholders of the need for detailed requirements, detailed investigations, complex questionnaires, proofs of concept, and a range of testing before making the system live on a production environment.
The size and complexity of this area is such that it could not be addressed in this series, but suffice to say that all the rules about requirement apply equally and there are a number of new concerns to be addesses.

Communication skills for project managers – Presentation skills

CAPE CANAVERAL, FL - JULY 03:  NASA's John Cha...

Image by Getty Images via Daylife

 Read Part one    Read Part two

Presentation skills – Part three

 

As part of a series on soft skills for project managers, last week I wrote a section on communication skills. It may seem that it is a little odd not to include presentation skills as a communication skill and I will certainly not argue with this. I have also delivered a section on persuasion skills separately for the simple reason that these are key skills that require individual treatment as opposed to a short paragraph in a single blog about communications, also because it would be impossible to give communication a reasonable coverage in a single instalment  and because in the world of Project management,  lot of people will associate communications with the communication plan as opposed to recognizing it’s importance in an every day sense.

Critical for project managers

Charts used in project management

In my early days as a project manager I survived some very gruelling relationships with programme managers and sponsors as a result issues around presentation and reporting and since then I have seen other project managers and  Business Analysts driven to distraction by bosses demands for reports that they could understand.
Not only do the normal rules of presentation apply, but the project manager also needs to be able pinpoint the concerns that stakeholders need updates on and exactly how they can be reported to in order that they feel satisfied and comfortable. Above and beyond all other aspects of project management, this one is critical to survival of the project manager.

First of all you need to try and reach an agreement on your KPIs at the outset, or as soon as possible. KPIs can vary quite substantially for example, you may be in a situation where budget is critical and the critical factor is that you don’t go over budget. In this case the stakeholder will need very reliable KPIs to warn you as soon as you begin to slip. In this instance EVA might be a useful approach.

It allows you to plan a cost schedule for delivery of the product over time and plot against that costs accrued and value created so that you can easily see when the budget exceeds target or the value creation misses it’s target. Creating a simple graph and explaining it carefully to your stakeholder may be the perfect way to give her a warm and comfortable feeling about the project.

On the other hand you may find that this idea is a good one, but your stakeholder just doesn’t understand graphical reports and you have to grind it out with columns of data and a slow painstaking presentation. See paragraph on styles. The safest way is to prepare your props to be ready for all types of communication and be aware of the reactions of your audience so that you can switch modes if needed and place the emphasis on a different method of delivery when it is required.

One rule is universally applicable to project management. Responsibility for the audience understanding the message correctly lies with the project manager.
Ed Taaffe

If you ever find yourself tempted to blame it on the denseness of your audience, you are very close to the time when you should consider an alternative career path. The buck stops with you.

Progress against schedule.

Gantt chart

The great universal way to represent this key KPI is the ubiquitous Gantt chart. They are the most used tool by project managers and mostly because they are the one thing that allow you to combine data with a graphical view in one place.
The Gantt however, has many weaknesses. Not the least of it’s weaknesses is it’s ability to cram too much information into a small report. Unless you audience have the ability to drill down then most of the information it shows can be as good as useless.  The fact is that very few people have access to a tool that will open and manipulate these files.
The commonest mistake made by PMs is to assume that their audience also have spent years working with Gantt charts and understand them well. In reality very few people are entirely confident with them and some of those have oversized opinions of themselves, the remainder are generally embarrassed to admit it i public and sit quietly nodding. These people will come back to haunt you.

The next common mistake is to assume that your audience are interested in performance over time, they may be worried about risk of slippage against budget, or looking for indicators of inaccuracy in your forecast.

Slack, and accuracy of prediction

A great way to analyse and communicate the accuracy of your predictions and show your progress against these is the PERT chart.

Pert chart

The pert is fundamentally a network diagram that shows your key products being deliver, or milestones being met in the order that is necessary. It demonstrates the difference between products that depend on others and products that can be delivered independently, thus creating a critical path.
The critical path is the longest route you can take from start to finish of the project. This is extremely important to be aware of, because the tasks that make up this critical path can not be delayed without delaying the project. Provided the time needed for each task in the critical path has been sufficiently estimated for in terms of time then the project will hit it’s target.

Estimation of the critical path is done by entering three settings for each task or product. The settings are Optimistic time (OT), Pessimistic time (PT) and most likely time (MT).  By manipulating this chart a little you can very easily display the best and worst case scenarios and keep a close eye on the most likely completion dates.  The commonest calculation used to start out with is:

ETA =(OT +4* MT + PT)/6

It should be clear by now that the message delivered by the PERT chart is very different form the one delivered  by an EVA graph or a Gantt.

Progress against budget

To present a report on your project’s progress against budget, one of the easiest graphical tools is an EVM chart.

EVM chart
EVM or Earned Value Method  is a fairly simple way to compare the  projected use of time and budget with the actual use of time and budget for the work completed. It is very easy to see a project delivering on time and not notice that it has used too much budget in doing so, or to see a project that is within it’s budget profile, but has not delivered sufficient value with the budget already spent. In both of these circumstances, the project will eventually run into trouble.  Without EVM or another tool to keep track, it is almost impossible to reassure stakeholders that ll is well.

EVM start out by defining milestones in terms of work done y date within cost and then records actual time, cost and work completed  to determine whether the project is on target. The tricky bit with this method is estimating the value of work in progress for incomplete products. Even a poor estimate at EVM will still provide a clearer view into the project’s true state than relying on Gantts and guesswork and should help to reassure your stakeholders.

Traffic lights

Traffic light report

RAG for red, amber, green is a very simple yet powerful way to report on a programme or portfolio so that people can quickly get a feel for the state of play. A simple dashboard can contain one clock for each project with just the three settings. A quick glance will then tell the stakeholder whether there are issues and how big they are likely to be.
Red reports will need detailed reporting, while Amber reports require a paragraph of explanation.
RAG reports overlaid on a programme PERT can be a very powerful tool for seeing instantly the likely consequences of a localised issue on the overall programme.

Innovation and customisation.

The key to good communication is to get to know the requirements of your audience and customise the delivery to suit them.  If there is no well trodden method out there then don’t be afraid to ‘innovate. Analogy is the key so create pictures and sounds that help them compare the subject to some concept they are more familiar with. Traffic lights, measuring jugs, barometers and all types of household concepts are regularly called on for help.

Critical to all presenters

There some rules that apply to everybody called on to make a presentation and here are a few of the key issues. The most important bit starts before the presentation. Prepare, Prepare, prepare. It’s that simple. Do your preparation well in advance so you can put it out of your head for a few days and then look at it again with a fresh viewpoint. Never deliver an important presentation for the first time to important people. Get some opinions first from knowledgeable people or a small subsection of your audience.

PowerPoint

PowerPoint and it’s equivalent have become an institution in the business world.  It has it’s fans and it’s haters, but it is still indispensable in many situations.  The key to using PowerPoint well is to use it only as a central roadmap for your argument and only for the visual aspects of your presentation.

NEVER write out your speech and read it out form PowerPoint, especially not with clever little animations on every line.

NEVER substitute PowerPoint for a paper or brochure or for speaking t your audience. Each communication tool has its own job to do.

DO stick to one idea per screen and one image per idea and limit text to one line per screen.

DO use your slides as a roadmap for your presentation

DO write out your presentation and practice it using the slides as your cue cards. Write extra notes in for your own purposes if you wish.

DO provide separate handouts that include your slides AFTER you presented NOT before.

DO use your slides as a backdrop and engage the audience directly, not via reference to the slides. YOU are the presenter  not PowerPoint.

DO agree in advance whether you are inviting questions as you go or you are providing for fixed periods when questions can be floored.

Presentation Structure

There is a very simple set of rules for presentations that work well and are easy to follow, here it is:

Start middle end presentation technique

It’s very simple and proven.  Introduce yourself and the presentation by telling them what your goal is and how you are going to do it then sum up what you have told them.

E.G.  My name is Ed Taaffe, I am an expert in presentation techniques and I intend to make you more confident in presenting to your stakeholders by walking you through some very simple but effective tools for making your presentations more successful.

Then show them the examples and finally close the presentation by saying something like.

So today we have seen three key techniques used by pros all over the world ton make their presentations more effective.

  • 1. Understand your audience and their needs and use analogies that will appeal to them to explain the concepts that concern them.
  • 2. Use a good mix of visual and oral delivery and encourage questions in a controlled way
  • 3. Use reports for written presentation, use PowerPoint for visual delivery and use your own presentation skills for oral delivery. The right tool at the right time in the right way.
  • 4. Prepare well in advance and seek and pay attention to feedback at every opportunity.
  • 5. Project management throws up it’s own unique communication challenges, be aware of these challenges and don’t be afraid to innovate to get your point across.

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

Reblog this post [with Zemanta]

Putting agile in perspective.

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.

Planning for project managers.

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 from 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 just to prove that you were right.  Read Maseena Zeigler on forbes about this subject
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 the 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.

Communication for project managers

Introduction to the series.comms encoding

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.
 

Reblog this post [with Zemanta]

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

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.

 

 

Whose fault is it anyway?

 

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake
Contract negotiation and on we go
Whose fault is it anyhow ?

 

23% of European projects cancelled, more than half overran by 50% or more.

When projects grow to any size, they invariably lose sight of the basics and especially they lose sight of the goals.

In the above study the authors uncovered weaknesses that have reached epidemic proportions, i.e

  •  inability to distinguish the critical success factors from Prince 2 speak ( total faith in methodology alone).
  •  Wrong KPIs from day one.  Inability to define and agree requirements. 
  •  Poor programme and business management leading to people believing they have done well when in fact they have missed the target completely, or that they are failing when in fact they are performing well.
  • Poor estimating of cost and time leading to inaccurate plans and poor management failing to follow good plans.
  • The wrong person in charge.
  • The wrong reason for starting in the first place. 
  •  Bad decisions made for the wrong reasons.
  • Unspoken political issues that were well known from the start, but could not be spoken of openly.

The most common failings are at the early stage and they are failings to understand:

1. Failing to understand what is best for the client. It doesn’t matter who is responsible for identifying and solving the problem, client or trusted adviser.  Things will go badly for both sides of the relationship unless it is done well before proceeding to delivery phase.

The challenges here are well understood, new technology in anything from fighter planes to productivity software is a challenge to understand, explain, evaluate, risk manage and decide on.
When it comes to an independent adviser this can be a little easier, but when the adviser is the supplier then it is more difficult to evaluate the accuracy of the material before making decisions. One of the biggest root causes of failing and vastly underperforming projects is poor choice of solution either through misunderstanding the problem, the operating climate, or the proposed solution.

The client has to take responsibility here, there is no alternative.

2. Understanding the problem and knowing what solution is chosen, but not understanding the macro and micro detail of exactly how the solution delivers and whether it really will fit in, switch on and work well enough to deliver on the promise.

Let’s say our customer is solving a scheduling problem and has agreed to invest in an automated scheduling solution. At this point it is hard to fault the logic. This is macro level. Now at Micro level our customer will have discussed certain things like how it interfaces with his ERP system and details like how it chooses who to send a particular emergency to.  All the big stuff and all the sexy stuff tends to get discussed.  What nobody has looked into is whether this system can deal with the fact there are many jobs where a dozen or more customers have to be visited at once in close proximity ( a warden controlled environment for the elderly is just one case).  This is the type of thing that is completely missed out on and grinds everything to a halt at some point, sometimes to the extent of scrapping everything and starting again, but more often by adding to the time and budget estimates, or dragging down the project slowly by reducing the benefits and spoiling the expected return.

3. Understanding the problem and the solution, but failing to understand the ambient climate that affects whether an expected outcome can be reliably predicted, or whether a more conservative approach is required, or perhaps and “all-in” gamble when there is nothing to lose and all to gain. Certainly there is a marked difference between the decisions being made today and those being made prior to August 2008.  I saw EDI solutions implemented at enormous cost at a time when a web page with HTTPS could have solved the same problem.

These three aspects are just small but very important reasons why projects will continue to struggle until they are taken more seriously.

Working relationships have to be enabled and supported, or they will hover close to litigation.

There are no big companies, just people who work at them and most decisions are based at some level on selfish motives. More often than not a supplier’s representative has to meet certain targets and will play the game to defend his margins.

In order to meet you half way he has to feel very confident that you can be trusted and he has to be motivated by gain. Don’t read this wrong, the gain I am referring to is the gain that results from satisfying his superiors, or exceeding their expectations, the gain for a customer representative is very similar though it will often be motivated more strongly by personal risk aversion.  Few organisations reward risk taking and even fewer forgive the risks that mature.

Easy solutions with negative undertones

The easy solution for the sales director, or suppliers project manager is to record what you ask for, make sure it is sufficiently close to what they are offering to keep them on a safe legal footing and then proceed in the knowledge that whenever it goes a little wrong, they will be very sympathetic and give you a bit of a discount on the extra work you needed. This strategy places all the risk on the customer and the further in the he commits the business, the less likely he will be to walk away and admit defeat. This strategy has developed into an art called “contract re-negotiation” that has begun to appear on CVs.

The easy solution for the customer project manager is to ignore the details and make it appear that he is placing all the responsibility for detail on the supplier. Then when it goes wrong they will wrangle and resolve it and he will continue to maintain his innocence and to castigate the supplier.

 

The correct solution is to negotiate the contract correctly from a position of enlightenment and to identify and spread the risk evenlySimplest case

The easy solution for the customer is to hire a red hot BA to document in great detail every aspect of the required solution, ask every question that needs to be answered and double check the fit with the business requirement, business strategy, prevailing conditions.  Having signed this off with business stakeholders, the risk has now been spread evenly and fairly.

The business makes a business decision and takes the strategic risks, the supplier works to a precise specification and prices the job accurately to leave an appropriate margin, the delivery team have only to concern themselves with identifying the risks that remain managing them attending to dependencies and keeping everything on track.
Any unexpected issues are easily categorised as such and there is a clear path for handling them appropriately.

More complex case

Many projects carry with them an element of innovation, this is the stuff of progress and it is critical not to smother it, but to do it well requires a marriage, or at least a fairly resilient affair between the business and the technology partner.

The answer is not surprisingly a combination of the two previous approaches. First of all a BA must do the job of defining the part of the project that is well understood in terms of business need and the supplier must bid for this as though it were the whole project, initially at estimate level.  The areas requiring innovation and carrying higher risk must be evaluated and risk managed so that a maximum cost and a likely cost can be established and the risk level can be well understood.

Once this is done an approach is defined that tackles the biggest impact risks as early as possible in order to allow an early exit if things go wrong.  Regular stage gates are planned so that there are opportunities to revise risk and cut losses early.  Managing the risk in this way makes this aspect of the project less likely to fail catastrophically and brings it out in the open early.  Working relationships tend to prosper in this type of environment and good relationships deliver good outcomes.

Risk management is like charity, it must start at home.

The first and by far the greatest risk to every project is the culture of the organisation.  As this report supports, many project managers turn a blind eye to political situations that can’t be discussed and proceed in the hope that all will be well.  Some of these situations include: mixed feelings in the boardroom and tripwires around every corner, Gadget freaks in the senior management who want to add on stuff they would like to play with.  Management who shoot the messenger, but can easily be fooled. People who get involved with the suppliers or their staff socially and undermine the project team.  There are many more examples of very serious risks that remain unspoken, but are responsible for a great many failures.

 

 

Reblog this post [with Zemanta]