the Bridger

August 23, 2008

What would you like sir?

Filed under: Requirements, product development, project management — Tags: , , , , , , , , , — admin @ 10:45 am

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.

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

3. A product must breakeven quickly, deliver a profit 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.
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 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 are 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.

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 form 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 wooley 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.

August 10, 2008

How many organisations can you name that actually use Prince 2?

Filed under: Organisational change, Systems, project management — Tags: , — admin @ 4:12 pm

 

I was asked this question recently and after some thought I had to admit that the answer is zero.

In fact, not only can I not name one, I have to admit then in more than ten years i have never worked in

 an environment that allowed me to use the essence of Prince 2, with the exception of one which hired me

 to establish and coach Prince 2 for them and one which used Prince 2 but couldn’t spell management let alone implement it.

 The standard thing in the UK is that every job spec for a project manager asks for Prince 2 and every CV claims experience or qualifications in it, yet it’s a fickle bird to track down.

I’m not suggesting that project management is poor in the organisations without Prince 2, in fact it can even be better. Neither am I suggesting that Prince 2 has not had a positive impact on the organisations that borrow bits of it.

 

If they are not using the methodology they claim to be using, do they have any  methodology?.

The essence of methodology is that for better or for worse, it locks you into a habitual process of ticking all the boxes and it provides a safeguard against missing  vital bits of the jigsaw at critical times.  Used intelligently, the bits you don’t need don’t have to consume any time or effort, but making the decision that you don’t need them as opposed to forgetting them is the life saving bit.
My answer to the above question is mostly no.
Based on my experience the majority of organisations include certain bits and leave out others and stop following any process by half way through.  It’s not an easy judgement to make, because  Prince 2 was intended to be adapted, so my judgement is made on the same criteria as CMM, if there is an identifiable process and it is repeated then they have a methodology.

Whether it is fit for purpose is another question entirely.

 What is wrong with Prince 2?

When I see a large complex software system not being used very much, I describe that as a failed project and if it is not being used I ask why it is not being used.

The answer usually falls into one of two camps: (a) It does not do what it is meant to do (b) It is too difficult to use. Following on that definition, I am naturally therefore assuming that to some extent at least, Prince 2 must be considered  a failed project.

My view and that of most of the people I have discussed this with is that problems with Prince 2 are:

1.       Too much complexity.

2.       Too much paperwork.


Complexity

You only have to look at the Prince 2 process model to get that sinking feeling. Of course once you have been trained in it, it all makes sense. The methodology, rather than the model.

The complexity is a reflection of course of it’s birth in the public sector where complexity, red tape and too much paperwork is so engrained it goes unnoticed by  all but the rawest new recruits.

The complex structure and language of directing a stage and managing a project and product breakdowns and so on, is a major turn off for all but the most determined stakeholders, all project staff and a great many project managers.
When stakeholders are confused about what you are doing and why, that usually spells trouble on the horizon, when your team are confused you are already in trouble.

 Paperwork

The same paragraphs can be found repeated in countless places all over the project paperwork and needs to be maintained constantly unless you want a lot of documents that contradict each other as they reflect different points in the maturity of the project.
People sign off these documents, but few ever read them and even fewer believe what they read in them.

I have a set of Prince 2 document templates that I’ve been carrying around for years and there are more than 40 documents in the file.

It is true that these documents don’t all need to be produced but even a few documents that are not read and understood is a big problem and here are the reasons:

1.       Communication is the single most important aspect of any project, when you hide that communication in a document, it is all to easy to assume that the message has been received. Not only has not been received, it may not have been read, let alone understood.

2.       Documents are boring and when you begin to bore your stakeholders they stop listening and this is the first step in a sharp decline towards project failure.

 How much of Prince 2 is actually on the critical path of all projects

 This is a tough one, because there so many scenarios in which a project might be created and used. For the purpose of my answer, I will assume the traditional project that is created to bring about changes of some sort that are outside of the day to day business of the organisation. This was the original driver for creating a standalone team with empowerment, budget and it’s own dynamic.

My answer is that the project board is a must, because this represents the business need and  customers of the business and other important stakeholders. A project board provides a sound steering mechanism to make big decisions when needed and to review progress through stage gates.
A project sponsor is essential, he/she can also be the project executive. The sponsor is the senior manager or director who provides the motivation and drive from the business and who uses power and influence to remove obstacles when needed. If he is also the executive he will take chair of the project board and keep them to their task.

A project structure is absolutely utterly essential because without this people will spend their time squabbling over roles and responsibilities and decisions won’t get made. It needs to spell out clearly who is who, who does what and the relationship of the team to the Project board. It should also spell out clearly the reporting and monitoring framework.

  

A business case is of course fundamental, because without this here can be no project and it should begin in outline form and remain a live document throughout the course of the project.

 The simple RAG report is invaluable for giving stakeholders a warm glow once a month.

 That is it for me. I can happily deliver a project with that collection plus a good project management tool to manage my plan and a spreadsheet for budget control.

 

What else do you need

Well here’s the seed for a lot of controversy. In my book, Prince 2 couldn’t deliver a boiled egg unless the project manager understands food and boiling eggs. Domain knowledge is what I am referring to and in my view it is critically important.  Of course it is possible, especially on very large projects to deliver something without this domain knowledge, but in any circumstance, it is still the weaker of two options.

Not only do you need domain knowledge, but you need to be a skilled people manager. Many people would include this the in what is wrong with Prince 2? Paragraph, but in my view that is unfair, because it is not a Prince 2 weakness but a weakness in management and recruitment practices.

The main job that a project manager does is to lead and motivate people not just a team of professionals, but also stakeholders many of whom may be critical or apprehensive of the project and often external suppliers with a whole different set of motives and drivers.
Not only is there a big diversity in the team, it is a transient team that has come together just for this project. That means the storming, norming and all the other difficult and unproductive stages of getting a team to work productively together.

 

 

Ed Taaffe

 

 

 

 

 




 

 

 

Why so many organisations are so bad at change and what it takes to get in control.

Filed under: Organisational change — Tags: , , — admin @ 11:51 am

In Managing change successfully (March-April 2008), sponsored by Celerant Consulting a number of interesting findings suggested that at the top of the agenda for business leaders over the next two years will be organizational flexibility for operational efficiency.

Interestingly the report also demonstrated that the success rate of change initiatives amongst 607 firms polled was as low as 50%.
The blame for failed change projects
51% put the failures down to “winning hearts and minds” followed by 31% citing “Lack of clearly defined achievable milestones” and then “lack of management buy-in ” and   ”poor communication”.

These responses don’t describe a failed change management programme, they describe non existence of a change programme, i.e little more than a wish.

Why do organisations struggle to change?

Well this is the subject of many books, so this blog is not going to attempt to discuss it in depth, but the key concepts to consider are that:

(1) when you put any group of people together in a team of any size, there will be power struggles, certain individuals will dominate and the rest will follow. This soon becomes a comfortable arrangement whereby individuals find ways to meet their needs from the team.

(2) When you move the goal posts in an organisation, you are effectively melting the glue and throwing all the pieces back onto a pile.  Hence the cries of pain. “How will I demonstrate my value to the team if  I don’t know what is required of me?” “How will I build a new power base”, “maybe there will no longer be any need for my skills”, “nobody really values me now, they just don’t realise that I’m dispensable”. 
This is senior managers crying out, so you can imagine how the lower levels are feeling.

Operations is rarely a big challenge, people on shop floors, in trucks, or wherever are usually happy enough to absorb change as long as they are treated well, equipped for the work and valued. Their unions may negotiate for concessions, but ultimately they are not the problem.

How could this be different.

Well once again there is a temptation to write a book, but there are plenty of those out there already,  what is needed is good old fashioned common sense and a bit of leadership.

If an organisation is to be steerable then there has to be an efficient communication of direction form the brain to the legs and an appropriate response from the legs. Not a hugely complex concept.
As we all know, intelligent people in a modern workplace can’t be coerced into anything successfully. At best they will pretend to comply and hang on indefinitely, undermining things at every opportunity. The alternative is to provide direction and leadership:

1.       Communicate a clear direction loudly, clearly and honestly until it is understood at not just a strategic level, but one whereby individuals can begin to see at a micro level how they can, or can not fit into this new team.

2.       Facilitate and orchestrate the team forming and norming instead of waiting for months, or years until the squabbling is over.

3.       Develop real value propositions for your key people based on their needs. If you are in doubt or want to get a head start in understanding their needs you can begin with Maslow’s hierarchy of needs and make sure that what you are offering them gives them an equivalent, or better level to what they have now and a motivator to get them going.
In simple terms their needs can be described as;  
The need to survive( not usually an issue)
The need for shelter (rarely an issue)
The need to interact socially ( this can be important)
 The need for personal development (now we are at the centre of it)
 The need to progress towards your life ambition.
These last three are the battle ground on which all the squabbles are fought and with a little planning and intelligent management action, much of it can be channeled into positive energy.

4.       If you can align your business goals to the individual goals of your key people, then you have a win/win scenario that is sheer magic.

5.       Now that you have created a healthy positive culture, have your key managers cascade this down all the way to the bottom layer

Who should do it?

The people with the skills to plan and execute this are senior HR managers and Change managers, but the person who must unquestionably own this whole process and be seen to own and believe in it passionately is the Chief Executive. It doesn’t necessary call for a lot of his time, but for quality time.

Ed Taaffe

 

Powered by WordPress