Project Management Software & PSA Software
| |
|
|
|
|
|
Creating your own improvement story: B Vasanthakrishna, Kornerstone (March 2012)
|
|
|
|
|
|
It is often difficult to maintain the ‘feel good’ factor that you experience at the beginning
of a project right through to the end. This is particularly true in software development
which has displayed a number of fundamental inadequacies over the years, building
itself an unsavoury reputation for failed and cancelled projects.
There is no doubting that software projects tend to have a very high incidence of cost
overruns, schedule issues and quality problems. Cost overruns classically point to a poor
estimation process – and one way to protect major investments and keep key
stakeholders informed is to include risk-based methods in your software estimation.
Estimation is at the heart of every project and business, and to understand the power of
estimation and its inherent influence on project management is to unleash the power of
true engineering.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Giving projects a clean bill of health: Peter Osborne, LOC Consulting (Dec 11)
|
|
|
|
|
|
Performing a review or ‘healthcheck’ of a project on a regular basis is a relatively simple and
inexpensive exercise when compared to the multi-million pounds that are at stake. A
healthcheck provides stakeholders, sponsors, and those tasked with managing the delivery and
impacted employees, with peace of mind that the business benefits will be realised within the
given time and resource constraints. Yet, in the same way that most people only go to the
doctor when they feel ill, the majority of organisations only perform a healthcheck if they believe
that something is fundamentally wrong.
Even if the warning signs are visible, there is a tendency to carry on with a project in the belief
that issues can be resolved by doubling efforts or by throwing more resources at them.
However, unless corrective actions that target the fundamental aspects of a delivery are
implemented early, in most cases, outcomes will not be realised or a catastrophic failure will
occur.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the eye of the beholder: John Brinkworth, Solution Identification (Nov 2011)
|
|
|
|
|
|
There are continual criticisms about projects going wrong and a generally held view that
projects rarely succeed. Yet while apparently self-evident, the determination of whether a
project is successful or not is difficult.
There are many different perceptions about what constitutes success in a project – and herein
lies the challenge. These perceptions can span from measurable success through to much
softer ‘feel-good factors’. So what viewpoint should be considered? 1. The end users. Do the recipients of the project’s deliverables, the end users, have what they need from it? If it
is a system, does it work as intended, enabling the tasks it supports to be achieved effectively?
Is it easy to learn and use? Does it make the users’ lives more efficient and less frustrating than
previous arrangements?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Claiming benefits: Michael Phillips, Phillips Associates (October 2011)
|
|
|
|
|
|
Benefits management is about enabling business improvement, and improving the value and
return on investment you get from projects. The focus is on assuring the actual realisation of
benefits, not on the delivery of the project itself; nor is it about the capability delivered, but the
effectiveness of the use of that capability within the business.
Benefits management involves: identifying potential benefits or dis-benefits; planning, modelling and tracking benefits; and the assignment of responsibilities and authorities. Its aim is a whole lifecycle approach to getting beneficial returns on investments. It is not a cost/benefit technique, nor is it a
technology, tool or an IT methodology. It is a management process, residing in the business and sitting alongside business
strategy and programme/project delivery. It is often used simply for measuring benefits being realised.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gateway to the future?: Duncan Sharrocks & Kenneth Tombs (September 2011)
|
|
|
|
|
|
Peer reviews come in many shapes and guises. Most are informal and low in method; a few are
high in method and rigorous in application. Those in the commercial sector usually have teeth.
Those in the public sector often don’t.
Reviews tend to focus on the ‘tin and plastic’ yet pass by the cultural and capability issues.
Programme and project management methods are now common, yet sophisticated industrial
projects are still delivered using no more than a spreadsheet or process notation tool, commonsense
and of course some attitude.
Wherever you may sit in this spectrum, a more formalised peer review is considered a highly
effective project assurance method. In fact, according to an official Independent Review, the UK
Government’s OGCGateway peer review programme is undoubtedly the most effective
mechanism government has in improving project delivery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rightsizing your projects: T Fox, G Coe & A Fieldhouse, Serco Consulting(Aug 11)
|
|
|
|
|
|
In today’s turbulent times, there has never been so much pressure to ensure that an
organisation’s key resources are focused on the right things. Creating the right ‘mix’ of change
initiatives – and extracting maximum value from the investment in these activities – is vital to
create or sustain a competitive edge.
So how can organisations be confident they have the right portfolio of projects and
programmes that are focused on the right things? Experience suggests that effective portfolio
management decision making that is based on strategic business objectives, and clarity around
expected benefits, can help organisations answer this question and create value for the
enterprise. Organisations inherently know they need to align their current and planned initiatives with their
future vision and strategic objectives. But whilst this is recognised as a fundamental element in
planning change initiatives, many companies still struggle to achieve this. The most common
issue is that of ‘clarity’.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nine steps to good governance: Graham Oakes (July 2011)
|
|
|
|
|
|
Project governance. A decade ago, most of us had never heard of this term. We planned our
projects. We defined roles and responsibilities. We tracked risks and escalated issues. We
managed our projects rather than governed them.
Then events like Enron came along. Governance became sexy. The technology vendors got
onto the bandwagon and started to rebadge their tools. To many people ‘governance’ has
become the new word for ‘management’. That’s sad, because clear thinking about governance
can add a lot of value.
Organisations manage projects poorly for a variety of reasons – unclear objectives, mismatched
priorities, insufficient resources, inconsistent processes, etc. Many of these problems stem from
one root cause: people making conflicting decisions about what to prioritise and where to
allocate their resources.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is PPM really a silver bullet?: Iain Begg & Ian Crawford, EndState (June 2011)
|
|
|
|
|
|
At a time when organisations are focused on driving value from their increasingly pressurised
projects budget, and sweating the resulting assets, PPM solutions potentially offer a way of
improving the management of your portfolio of projects and programmes.
But whilst it is certainly true that PPM solutions can add significant value to your organisation,
are they really the ‘silver bullet’ that many claim?
In judging the value of PPM, it is clear that to be truly successful, every organisation must
develop the solid foundations required to underpin success.
In the case of effective portfolio management, those foundations are the necessary disciplines
required to manage your projects in support of your organisation’s strategic (and sometimes
tactical) objectives.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Transition revamp: Pauline Geran (May 2011)
|
|
|
|
|
|
Managing a major project is never easy – especially when it involves considerable changes. But having a clear understanding
of where you are now and where you want to be by the end of the project is certainly the best place to start. The project should
be viewed as a journey of transition or a period of change, and there’s a lot to consider if you want to make it as painless a
journey as possible.
The majority of transitions go over budget, are late and create service disruption. Transition is a journey that starts much
earlier than most stakeholders realise. It begins with the need for change either through necessity or choice and it is from this
point that the most appropriate person needs to own the process to have any chance of success.
The journey can be thought of as the transitional period and takes into account three elements – the decision making,
supported by a signed-off business case and definition of ownership.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Agile Financial Times: Ian Brookes, Cake Solutions (April 2011)
|
|
|
|
|
|
Agile project management practices are currently becoming a recognised standard in the IT and other industries. Does this
mean that agile techniques are much better than the more traditional project management approaches, or do older project
management methodologies still work? This article explores the pros and cons of both approaches – but it is undoubtedly true
that in these times of heightened awareness of the requirement to ‘do more with less’ or to ‘do more differently’, agile is
enjoying a surge of interest.
Before we explore the agile world, firstly what is meant by ‘traditional project management’? Focusing on IT projects, this is an
approach that treats software development as if it were a straightforward process of turning requirements into specifications or
lines of code; and attempts to plan every detail of this process in advance and measure it precisely. Add to that, rigorous
documentation, staged processes and fixed deadlines, and the danger is that the interaction with the business in the traditional
approach can become inflexible and inefficient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Say hello to EVA: Steve Kirk, SGK Consulting (March 2011)
|
|
|
|
|
|
Sometimes the simplest questions are the hardest to answer. A few years ago, as a stressed
and overloaded professional services manager, I remember one of my biggest headaches was
trying to get a realistic view of how well my staff’s projects were progressing.
Every month I’d sit down with my project managers and review the performance of each project
– but when I asked the question, of course, I got a very subjective answer.
Tony was a born optimist and fiercely proud of his reputation, so the answer was invariably
“Everything is fine and I’m ahead of schedule and under budget” while Chris was a confirmed
pessimist and his answer was “Everything is going wrong, the schedule isn’t worth the paper it’s
written on and the budget was never adequate in any case”.
In both cases, the reality was never quite as good or as bad as it was presented, so I always adjusted their reports to take the
‘human factor’ into account. Despite that, I was always painfully aware that I was basing decisions on a very subjective
assessment of reality.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Becoming benefits-led: Hugo Minney, Minney.org (February 2011)
|
|
|
|
|
|
‘Benefits management’ is about identifying what your organisation is trying to achieve, then
aligning your efforts so as to achieve as much possible within the resources you have. Benefits
are real things like profit; reduced risk; more business opportunities or the capability to take
advantage of more opportunities. However, most projects seek to deliver specific controllable
outputs, such as a new CRM package or a new building. There’s a world of difference.
For the project team, benefits management is the ‘why’ of your project – delivering what makes
the biggest difference to your organisation or client. So how can you get people focused on
benefits, and how can you best get benefits delivered?
The first key factor is that projects are often dependent on other projects to deliver benefits. Very
few projects exist in isolation. Projects line up in chains, where one project is dependent on the
outcomes from the previous one. Projects spawn sub-projects and combine into super-projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Leadership challenge: Adrian Fieldhouse & John Brinkworth, Serco (July 2010)
|
|
|
|
|
|
The world has changed. The credit crunch and economic downturn have created a difficult and uncertain future, placing a whole new set of pressures on organisations. The need to be operationally efficient has never been greater. But responding to this challenge is hard, especially when you consider that many projects and programmes fail to deliver their expected benefits. To be successful, the programme leader needs to consistently apply a set of simple but effective processes; remain focused on the required outcomes; and manage a multi-disciplinary team whose configuration changes as delivery progresses and you move through the different project phases. The project leader can achieve this by addressing these three questions at each key project stage: are we doing the right things? Are we doing them in the right way? Are we able to exploit what they deliver?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Choosing a new PM: Cliff Mills, NCC Research (May 2010)
|
|
|
|
|
|
Every organisation has projects: they may arise as part of a master plan or strategy or in response to a developing challenge or problem. Some are relatively easy to manage, others can be vital to the company’s very existence. It is managing these highly complex and often time-critical projects that presents the major challenge. In addition, projects do not normally exist in isolation and organisations usually have a portfolio of projects that need to be prioritised and are quite often competing for attention and the same resources. Risk is a feature of projects, and project management has much to do with identifying and managing the risks a project may face. A project is intended to deliver step change. Such change may transform processes, performance or culture. Ideally organisations also want projects to run on time, meet quality objectives and to cost no more than the budget. When milestones are missed, the result can be both financially and in some cases publicly painful. The more control and timely information you have about a project, the better your capacity to manage a successful outcome.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When excellence is not enough: Robert Buttrick (April 2010)
|
|
|
|
|
|
The only reason for undertaking a project is to add value to an organisation in pursuit of its
strategic objectives. Any project which does not do this is useless or a sink for scarce
resources.
Projects, however, do not directly create value. They deliver new capability to an organisation,
but it is the organisation itself which creates value by using those capabilities.
Value creation (benefits realisation) usually happens after a project has been completed.
Thus, benefits realisation cannot solely relate to a project but applies to the organisation as a
whole.
Add to that the fact that many projects and day-to-day activities may contribute to the same
benefit measure, and it is often impossible to separate which activity or project have produced
which effect.
A pragmatist may argue that if the total benefit is achieved within any overall constraints, then it is not essential for such back
analysis to happen. Most business leaders are pragmatists!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The art of EPMO: Ivan Lloyd, CPS (March 2010)
|
|
|
|
|
|
As business confidence starts to recover, companies are continuing to demand value in every
project they run. Organisations are asking tough questions about potential and live projects: are resources being consumed appropriately?; and are we achieving efficient utilisation?
This in turn raises a number of issues, including: can the company provide the necessary programme and project controls to stabilise the
fluctuating demand for people?; can the company cut resources and pressure people further to deliver more, or should there
be change in our cultural, organisational and behaviour habits?; and can enterprise project management (EPM) technology solutions replace people’s skills and
abilities?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Learning to lead: Steve Kirk, SGK Consulting (February 2010)
|
|
|
|
|
|
“I’ve worked with my stakeholders to identify their requirements. I’ve talked to my experts to
work out the scope of my project and estimate each task. I’ve painstakingly put together the
schedule and budget and documented it all in a project specification. I’ve even agreed a risk
and governance plan with my sponsor.
“I’ve had the project kick-off and distributed the work packages. So how come nothing is
happening? I’m already late for the first milestone and every time I chase up my project team, it
seems they are too busy on other work to help me. Why isn’t this going better?”
Does this scenario sound familiar? Have you rigorously followed ‘best practice’, only to run into
a thick blanket of apathy and indifference? It just doesn’t seem fair, does it?
The answer is to start behaving as a leader, not just as a manager.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Building blocks for success: John de Newtown, John de Newtown Associates(Jan 10)
|
|
|
|
|
|
Recent events in the financial sector have more than demonstrated that we live in an era of
increasing change. So whilst organisational performance will continue to depend on core
functional competences, the ability to manage change is becoming more important in
determining longer-term survival and growth.
The change programmes that organisations embark on will manifest themselves as projects of
all shapes and sizes – ranging from mini-projects (eg, installing a new office PC system) to
mega-projects (eg, the new St Pancras station development).
In the past, the ability to manage these programmes was seen as a special skillset, only
needed by ‘project people’; nowadays it is widely recognised that these skills are increasingly
part of the day job for all concerned.
In recent Evaluation Centre articles, John Brinkworth has discussed the challenges of defining
project success and Barry Tuckwood has suggested some of the key factors that can contribute
to a successful outcome.
This article aims to provide a set of guidelines to help those managing projects to assess whether they are on track for a
successful outcome and, if not, to suggest some practical tips that may help.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Putting people first: Terry Cooke-Davies, Human Systems (November 2009)
|
|
|
|
|
|
Planning and process have long been seen as the real heart of project management. After all,
“You have to build the walls before you can put the roof on”, project novices are told. It is the
order of things that matters, and it is the level of organisation needed to ensure things happen
in a precise order – that is where the real skill lies.
As with most broad statements, there is some truth in all this, but it doesn’t tell the whole story –
perhaps not even a fraction of it.
The problem is that people, rather than machines, ‘make things happen’ and whilst human
beings are an incredibly powerful resource, they are unpredictable and often irrational.
Understanding what motivates them and influences their emotions is critical to learning how to
control and manage them.
The more we realise the significance of this, the more we understand how limited planning and process skills are in what they
can achieve on their own!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What is success?: Barry Tuckwood (October 2009)
|
|
|
|
|
|
There are hundreds of articles and papers that discuss project success – yet there is no real
consensus on what it is.
What do we mean by project success? People often refer to the time-cost-quality aspects alone,
with some consideration given to the project’s outputs. But while time, cost and quality are
easily measured, the real appreciation among stakeholders, by which success might more
reasonably be judged, is more difficult to assess.
Nor is it sufficient to measure success through return on investment, especially when there are
diverse users involved which makes the measurement of benefits complex.
The context has to be simple: project success should be clear to everyone involved and the
expectations match what can realistically be achieved.
In my view, then, project success combines the products and the management of the project.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The 'I's have it: Benita Sutton-Cegarra, BJC Europe (September 2009)
|
|
|
|
|
|
In business today, 80% of strategy is never implemented. Imagine how much time, effort and
money is wasted in the process. So why does this happen?
In most large organisations, the strategic direction is usually defined and developed by a small
group at corporate headquarters, taking external factors into account, but not involving the
operational organisation. It is a one-way process and the organisation does not have the energy
to deal with something they perceive to be so divorced from reality.
In small companies, there is often just one person at the centre, who believes they have to
make sense of everything and who ends up trying to do everything. Usually, they achieve only a
fraction of what needs to be done because there is too much to cope with alone. The
employees don’t offer help, as they don’t believe it’s their role.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The problem with PPM: Peter Andrew, ea Consulting Group (May 2009)
|
|
|
|
|
|
Businesses spend money on only two things – current activity and change.
Of these, current activity (or business as usual – BAU) is necessary and unavoidable. So
spending on this can be managed, and some costs can be saved at the margin, but it is largely
non-discretionary.
Spending on change, however, is generally discretionary. Some change is externally imposed
and therefore unavoidable – typically through regulation or sometimes the need to react to
competitors. However, for the most part, businesses can choose how much they spend on
change, and how they spend it.
Management of this discretionary spend – the investment portfolio – is always an important activity. And in the current
challenging economic climate it is even more vital that companies spend money on the right projects, and deliver them in the
right way.
Careful decisions are needed both at the start and throughout the life of projects, confirming regularly that the investment
remains on track to justify predicted benefits.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fed up with Gino?: Steve Clarke, Onemind Management (April 2009)
|
|
|
|
|
|
Whether your initiative is to counter global warming, host the Olympics or improve the business
of an organisation, effective programme and project management is essential. And that in turn
is deeply dependent on effective governance. But this too often results in ‘Governance in Name
Only’ or Gino – and the cost of continuing to live with Gino is much too high.
My experience in designing and implementing governance arrangements for a range of
programmes and projects is that there is widespread misunderstanding about how to encourage
senior management to adopt suitable governance behaviours.
So how do you establish effective governance? This article sets out to be deliberately
challenging on the issue. By throwing down the gauntlet to conventional views, I hope to kickstart
a long-overdue discussion on why organisations find it so difficult to establish effective
governance – and I invite you to join me in that discussion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cut to the chase: Alan Fowler, Isochron (March 2009)
|
|
|
|
|
|
In a recession, a programme must deliver a return on investment and waste no time in doing
so. It becomes crucially important to realise benefits in an elegant and economical way – there’s
just no money and no time for anything else.
At first sight the solution would appear to be ever-better planning and tougher management of
scope, time, resource and quality. Control seems to be at the heart of delivery. Yet no matter
how good your preparation and governance, unforeseeable things will happen and threaten
your ability to achieve expectations.
The history of a programme will be written after it is over and cannot be written in advance.
Understanding comes with hindsight. “Life must be lived forwards but can only be understood
backwards,” said Soren Kierkegaard, the philosopher; and this is as true of programmes as of
the rest of life – including living through a recession!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Success in uncertain times: John Brinkworth, Serco Consulting (February 2009)
|
|
|
|
|
|
We are currently facing uncertain times, with constrained budgets and rapid unpredictable
change. In relatively calm economic circumstances, most programmes are able to run to
completion as originally envisaged – but now pressures and changes may mean that a
programme’s future needs to be re-examined.
A programme that was expected to run for a significant length of time may need to be finished
sooner than originally planned. Resources can then be released and possibly redeployed onto
other priorities, which may have arisen at short notice.
And even if your organisation has the comparative luxury of choosing when to end a
programme rather than having to stop it immediately, you are faced with a difficult decision:
when is the optimum time to do this?
For while projects often have clear-cut end points with identifiable deliverables, programmes are different as they generate
outcomes that are more about achieving business change. The question you have to answer is: has the programme
succeeded enough to declare it complete?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'Earthquakes' in the project portfolio: Graham Oakes, Graham Oakes Ltd (Jan 09)
|
|
|
|
|
|
Computer games are a serious business. A game for a current-generation console (say an
Xbox or Playstation 3) can cost $20 million or more to build. Even back in the mid 1990s, when
my experience with the industry began, a game could easily cost $2 million to develop. The
company I worked for had about 60 such games under development at any one time.
My company, like most in the industry, had a problem. Projects slipped. They often slipped by
months or even years. And this didn’t do a lot to help our reputation with retailers, reviewers
and customers. Perhaps even more critically, it made it impossible to predict cashflow. And so I
became part of a team that was set up to bring predictability to our project delivery.
Each member of the team was responsible for providing an independent view of the status of
about 10 projects in the development portfolio. Each week we looked at what our projects were
producing and tracked this against the original milestone schedules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Putting people first: Sean McDonald, ESI International (November/December 2008)
|
|
|
|
|
|
On any given day, you probably have a lengthy to-do list sitting on your desk or computer, filled
with projects and tasks to which you will eventually attend. Depending on your mood, directives
from your boss or the way the economic stars have aligned that week, you are constantly
shuffling these tasks in terms of priority.
Organisations, no matter how big or small, do the exact same thing every day as they struggle
to effectively determine what needs attention yesterday, what needs it today and what, if
anything, can wait until tomorrow.
Complicating the issue, most companies are bombarded with new strategic initiatives and
opportunities every month – some of which align with overarching goals, and some of which,
ultimately, do not. Choosing which of these items makes it onto your organisation’s to-do list
can be difficult and costly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perfecting partner projects: Hartley Millar, Management Partners (October 2008)
|
|
|
|
|
|
Organisations are steadily improving the methods they use to manage and co-ordinate projects.
At the practical level, using a dashboard approach to control a project is becoming
commonplace. After all, the opportunity to aggregate the data gathered – often in real time –
from those directly involved in project delivery seems like the Holy Grail of control.
The advantage of this approach is that, rather than confronting managers with a mass of detail,
it is possible to present an overview and ‘bore down’ on any particular areas where questions
arise.
It may not quite be a basis for managing by exception, but this clearly addresses the issue of
information overload for managers in complex projects.
However, such data only becomes useful when it is put in context, typically by comparing the actual situation with what was
planned. That, for most systems, is the project plan – and it’s the project manager and steering committee who own this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Painting the bigger picture: Hugh Buckley, Quortex (September 2008)
|
|
|
|
|
|
Most medium to large-size companies manage a portfolio of dozens or even hundreds of
projects to deliver change and new products into their businesses. Many of these companies
use established project methodologies to help manage and deliver this portfolio – such as
PRINCE2, PMBOK or other ‘inhouse’ variants developed over the years.
However, the results and delivery achieved can still be disappointing despite the use of these
methodologies. There may be many reasons for this: the right departments not being engaged early enough; failure to take account of the wider business impacts of a project and not just the IT impacts; gaps in responsibilities across the functions; poor understanding of what each function really ought to deliver; and lack of the right skills and expertise in key areas.
Sometimes, the problem can come down to the simple fact that the business can’t quite harness the capability due to politics,
lack of trust or loss of focus – especially if the linkage between the true goals of the organisation and ‘how I/my team contribute
to those goals’ is lost.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don't forget the Q word: Steve Kirk, SGK Consulting (August 2008)
|
|
|
|
|
|
Do you remember TQM? How about ISO 9000? Or even BS 5750? For those of you like me
who’ve been around a bit, it will bring back memories of quality circles, statistical process
control and lots of written procedures. But for those of you too young to remember, it may just
be a list of meaningless acronyms. In which case, let me explain that this article is all about the
‘q’ word – quality – and why it’s as important as ever to your business and your projects.
You see, although the great management consulting fads at the moment are technology
breakthroughs like Web 2.0, mobile working and SOA, back in the 80s and 90s when the
internet was something only academics and defence companies had heard of, quality was the
big thing that no self-respecting MD would dare ignore.
No longer were companies just concerned with efficiency and productivity, now they were
focusing on customer satisfaction, the cornerstone of quality. Why? Because it was seen as a
great differentiator between you and your competitors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's not what you do...: Martin Taylor, Changethreesixty (June 2008)
|
|
|
|
|
|
So you have used Evaluation Centre to help make a decision on which project management
software solutions to review. But what approach are you going to take to arrive at the final
decision?
It makes sense to use a straightforward scorecard, including all the key criteria that you require
from the software, with all members of the decision-making team providing scores.
However, what is equally important is how you feel about the people you will be working with –
the type of relationship that will be established with the software provider and what type of
company they are. Ask yourself: can I really work with these people?
It is likely to be a different type of relationship when you are in the evaluation process (when you are more in control and the
software provider wants to add you to its client list), compared to when you are a customer and in need of after-sales support. So
make sure you undertake your due diligence thoroughly, research the product, obtain references – and preferably visit them –
research the company, attend other demonstrations or user group meetings, speak to colleagues and check out their experiences.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stand and deliver: David Walton, Bestoutcome (April 2008)
|
|
|
|
|
|
Why do projects and multi-project programmes so often fail to deliver a real return on
investment? In many cases, the root cause can be traced back to the start of the
initiative, before planning has even begun. Quite simply, there may have been a
fundamental failure to ensure the underlying business case was rock solid.
The first step to achieving a successful result, based on the business case, is to agree
what value you expect to be delivered by the investment over its working life. In short, be
absolutely clear about the whole point of spending the money.
By clarifying the value factors right at the beginning, you can ensure the project or
programme will achieve its real purpose. But it’s surprising how often this vital step is
only partially dealt with.
Another fundamental issue is that project managers – the supply-side of the endeavour – may regard a successful
outcome as delivery to budget, on time, at the right quality, and to the requirements specification.
Once this happens they regard the job as done – but that is only half the story. The other half is the value or business
benefits the investment will deliver to the client – the demand side – after delivery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Getting projects in a solid state: Dr Richard Seabrook (March 2008)
|
|
|
|
|
|
It is a cliché within the IT industry that projects go over time, over budget and don’t deliver what the users want. The bigger the
project, the more dramatic its failure; grandiose projects are now widely expected to fail simply because they are large scale,
never mind any of the other possible risk factors.
In fact, the repeated failure of IT projects to hit their target is a consequence of the Second Law of Thermodynamics. The
Second Law (see Box), inspiration for a song by Flanders and Swann, and with a large part in Tom Stoppard’s play Arcadia, is
widely regarded in scientific circles as the supreme physical law.
C P Snow regarded knowledge of the Second Law as the crucial test of the breadth of a person’s education; he said, in The
Two Cultures, that to be ignorant of it is the scientific equivalent of never having heard of Shakespeare.
There are several ways of stating the three Laws of Thermodynamics, and the Second Law in particular.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Projects without borders: Elizabeth Harrin, Spire Healthcare (February 2008)
|
|
|
|
|
|
The world of business is continually shrinking: we work in an environment of real-time
communication with colleagues on the other side of the world and online translation tools. Even
small companies can operate internationally, with outsourcing agreements and partners
overseas, which means project managers in organisations of any size face the challenges of
managing international projects.
And that means far more than just working out that when it’s 9.00am in Paris, Texas it’s 4.00pm
in Paris, France. International projects come with two main challenges: the people you are
working with won’t necessarily work in the same way as you, and the people you’re working for
won’t necessarily want the same things.
The first step in being able to address these challenges is having an open mind. National culture plays a big part in how we
act, and we can’t change that – we can just learn how to make it work for everyone concerned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perfect partnership?: Steve Kirk, SGK Consulting (January 2008)
|
|
|
|
|
|
If you were asked to define the top five critical success factors for any business change project,
you would probably come up with a list something like this: strong leadership; well-defined requirements; effective business change; prudent risk management; and a compelling business case.
But how often are projects started without a clear responsibility for these areas? It’s no good
paying lip service to them and just expecting them to happen; we all know that leaving things to
chance isn’t the most effective way of getting things done.
Instead, wouldn’t you rather have the resources with the skills to address these five areas assigned to your projects?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PRINCE: purple pain?: Danny Thomas, Searchlight (December 2007)
|
|
|
|
|
|
A quick glance at the job pages will confirm what virtually every project manager already knows:
if you want a career in IT project management, you have to have PRINCE2 skills. Whether you
are permanent or freelance, junior or senior, almost every job advert makes it clear that being a
PRINCE2 practitioner is no longer optional.
So why is it then, once the job is won, so few of these positions actually require the successful
candidate to exercise that practitioner status? With the exception of a few government
organisations, generally the police forces and the military, most people actually adopt PINO –
Prince In Name Only.
There is general agreement that a project management method is a good thing: repeatable
processes, a strong governance ethos and a ready supply of qualified professionals. There is
also widespread acceptance that PRINCE2 is the only method that fulfils the required criteria
and has many strengths. Without question, the governance structures PRINCE introduced – in particular a project board with
supplier and user representation at a senior level – have been extremely powerful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wall-planner heaven?: Gareth Lewis, Pserendipity (November 2007)
|
|
|
|
|
|
How did we use to manage resources and projects in the days before computers? One halfterm
when I was young I remember going to the factory where my Dad worked and being very
impressed by a wall-planner which had multi-coloured job cards at various stages of completion
allocated to what appeared to be war heroes, but were actually the nicknames of the foremen of
the teams responsible.
I suppose for the time it was extremely sophisticated, and represented an almost foolproof
status-monitoring system for management. Nevertheless, it had many defects in practice. It was
only three-dimensional, since it specified the job details on the coloured card, the team on the
one axis and the status on the other. It was updated by only a single user (the factory
manager’s secretary, a frightening – to me anyway – lady), thereby minimising ‘input’ errors;
and while anybody could look at it, access to the factory office was restricted to those who had
taken off their work boots!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Project myths and trends: Kelvin Kirby, Technology Associates (October 2007)
|
|
|
|
|
|
The project management software marketplace has come of age. In the early part of this
decade, the market was limited to a few key players. But as mainstream vendors – including
Microsoft – realised the huge growth potential in the market, they either
developed their own software or acquired existing technology from a key player in the
market.
Microsoft, for example, bought UMT Consulting in January 2006, and immediately secured its
place as a vendor in the PPM market. UMT was a well-known and respected organisation
selling high-value, high-benefit consulting services and applications to help organisations
analyse their corporate objectives, marketing strategy and product portfolio and then align their
projects and programmes to realise maximum ROI.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Beyond conventional management: Dom Moorhouse, Moorhouse Consulting (Sept 07)
|
|
|
|
|
|
Lack of effective engagement with stakeholders is a well-known cause of programme failure. As
a result, stakeholder management is increasingly recognised as a relevant discipline – and
there are already many tools and techniques available addressing this area.
But these techniques over-emphasise a mechanistic ‘left brain’ view of the world. What is really
needed is something quite different.
Of course, there is no panacea that will confer instant success on your programme – no magic
framework, technique, tool or model. If anyone attempts to sell you one, we politely suggest
they have never left the academic lab.
What is required, conversely, is for a proactive attitude, or state of mind, to be enthused across
the programme team. We refer to this attitude as ‘PRIME Intelligence’.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gateway to the boardroom: Roy Illsley, the Butler Group (July/August 2007)
|
|
|
|
|
|
Many IT departments are implementing, or considering implementing, a portfolio management
approach to ensure that they are spending their time and money on the projects that will deliver
maximum value for the business.
However, there are some fundamental points that need to be considered and actions taken if an
organisation is to obtain the results anticipated from portfolio management.
Companies are discovering that in the new global marketplace, the emergence of low-cost
competitors is forcing them to review their own cost base, and effectively do more for the same
spend. Meanwhile, Butler Group research suggests that 80% of an organisation’s IT spend is
used for non-new value adding activities, such as support and maintenance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Who's in charge?: Hartley Millar, Management Partners (June 2007)
|
|
|
|
|
|
Poor projects collapse. ‘Good’ projects take on a life of their own. But with a life of their own they can easily: lose sight of the business case; deploy technology for its own sake; confront internal stakeholders with over-the-top ‘requirements’ and supposed dependencies; lose sight of external stakeholders’ (including customers’) interests; and continue themselves and demand resources long past their sell-by date.
Clearly project management should be held to account for projects getting out of control – or failing. But who is ultimately
responsible for appointing and controlling project management? And how can project managers know enough about the
environment to be able to moderate their demands, or to take account of factors that are outside the scope of the project
itself?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Demystifying PPM: Mike Beard and Karen VanSant (March 2007)
|
|
|
|
|
|
Project portfolio management (PPM) benefits an organisation by making visible the ‘basket’ of enterprise projects to
management and executives – enabling them to define and track projects according to their value and relevance to enterprise
goals.
PPM is not a new concept. Commercial companies that pioneered programme management aligned to US military projects in
the 1950s transferred these project and portfolio management approaches to their commercial efforts.
In mid-2006 the Project Management Institute (PMI) released the Standard for Portfolio Management. This is a framework that
represents generally recognised good practices in project portfolio management.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
One size doesn't fit all: Siân Ferguson/John Fisher, Novare Consulting (Feb 07)
|
|
|
|
|
|
At the heart of the PRINCE2 methodology is a flexibility that allows it to cope with any size of project. Yet despite this inherent
adaptability, when it comes to small projects, one size doesn’t fit all and a ‘micro’ version of PRINCE2 is required. And judging
by internet searches, consultancy offerings and trade magazine content, there seems to be significant interest in organisations
in such an approach.
Organisations are concerned about delivery of small projects for two reasons. The first is obvious – companies tend to have
lots of small projects! The total value of these initiatives in some organisations far exceeds the budget, benefits and impacts of
their larger projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
One version of the truth: Steve Kirk, SGK Consulting (January 2007)
|
|
|
|
|
|
I remember when I was managing a portfolio of projects at my last employer, the most stressful
moments came not when I was eyeball-to-eyeball with the customer in a project meeting, but
when I was in management meetings with our finance director.
Don’t get me wrong, he was a nice enough chap and we got on famously, but it often seemed
we were talking about different projects such was the chasm between our respective views. You
see, as a project/programme manager my focus was on getting things done – problem solving,
managing work and planning – while my FD was more worried about tracking the money –
recognising revenue, absorbing costs and forecasting the final impact on the company’s bank
account.
Nothing surprising about that, of course, but the way we worked and the systems we used
reflected our own goals, and trying to reconcile them was virtually impossible. It did appear that
we had two versions of the truth.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Getting a good review: John Brinkworth, Serco Consulting (December 2006)
|
|
|
|
|
|
The media regularly report that IT projects continue to run into problems and do not always
deliver as expected. Surveys claim that between 50% and 70% of IT projects fail to some
degree. This is surprising and concerning, since good practice for project management is welldefined
and well-documented.
Managers involved in project governance are faced with the serious challenge of how to reduce
the chances of their projects running into trouble. Project assurance can be the answer.
But how can you tell the difference between good and bad project assurance? Good assurance
can help to improve the chances of a successful outcome; whereas poor assurance can impose
more bureaucracy without improving delivery chances.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Route to rapid change: Benita Sutton-Cegarra, BJC Europe (November 2006)
|
|
|
|
|
|
Being able to respond quickly and effectively to customers’ needs is paramount. Unfortunately,
the systems and processes used in many organisations have not proved able to keep pace with
the rapid business changes that occur within companies and the external environment.
Large-scale systems and business process change programmes, such as a SAP
implementation, take years to prepare and implement, and the external environment doesn’t
stop changing to wait for the implementation to be completed. So what do you do when your
organisation needs results fast?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The pleasure of repeating yourself: Stuart Cooke, CEC Europe (October 2006)
|
|
|
|
|
|
Projects continue to fail at an alarming and unacceptable level. According to the Standish
Group’s CHAOS Report (2004), 60% of projects fail because they: overrun time estimates by 84%; overrun cost estimates by 43%; substantially fail to support business processes; and substantially fail to deliver benefits.
However, process maturity models and assessments clearly indicate that a defined and
repeatable process substantially improves an organisation’s project delivery capability. These
processes, or methodologies, have been around for many years, especially in the IT arena. And
now methodologies are evolving to be more generic so they are applicable to a broader range
of projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sponsorship, leadership and PM: Robert Buttrick, Project Workout (September 06)
|
|
|
|
|
|
The function of project sponsor is gaining recognition as a vital leadership role in making
effective change happen. Many organisations have ‘institutionalised’ the role – which
may also be called project owner, senior responsible officer or project director. But who
is this person accountable to? If, as a project sponsor, you don’t know who you are
accountable to, you are not accountable!
Some organisations are mature in terms of how their project management
accountabilities co-exist with other formal leadership roles. Others are not. In small
organisations (or autonomous small business units within larger organisations), the
accountability for overall leadership and direction is usually obvious. It will be the CEO
and their leadership team. There will only be tens of projects underway at any one time,
a number which should be relatively easy to handle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It shouldn't be a lottery: Alan Fowler, Isochron (August 2006)
|
|
|
|
|
|
I once asked a director of IT strategy what he thought his company’s track record was in
realising project benefits. He laughed and said, “About half a percent, I should think”. Of
course, he was joking, no-one had really measured it and it wasn’t that bad. Well, not quite
that bad.
It’s a serious issue. In 1996 Capers Jones pointed out in ‘Patterns in IT System Development
Failure and Success’ that really large software systems can “cost more than building a domed
football stadium”. Studies of a sample of eight IT developments and business change
programmes carried out in private sector companies in the UK during 1996-98 yielded the
following total costs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
21st century PM: David Hofferberth, Service Performance Insight (July 2006)
|
|
|
|
|
|
The movement to a services economy, and its emphasis on managing projects, will drive
economic growth in all developed nations. Transformational thinking, that the project is the
centre of economic growth going forward, is permeating the executive suites in every industry. It
also bolsters the need for greater discipline in project management.
Business solutions that optimise the benefits of project management have significantly
increased in demand over the past decade. These solutions, termed ‘services automation’ for
the variety of project and services-driven organisations they support, are becoming an integral
part of business.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Keeping the faith: Tony Davies, addACUMEN (June 2006)
|
|
|
|
|
|
My wife – now of 40 years – is a fairly sparky personality. One weekend when the
children were small, I failed to come up to scratch and she went to her mother’s home
for the weekend. She returned on Sunday night – I was on duty the following morning –
to find the house in good order, the nappies laundered and put away, the children
asleep. “How did you do that?” she demanded. “Simple, I don’t know why you make so
much fuss…it is just that I haven’t slept since you left.”
The Guinness Book of Records shows that the record for building a four-bedroom house
from a standing start is 3 hours 44 minutes and 59 seconds. Built in March 1999 in New
Zealand by Habitat for Humanity it is an extremely impressive feat. The planning took 14
months. Both of these examples demonstrate the balance between execution and obtaining clarity. I would like to discuss this in
relation to projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The reluctant project manager: Steve Kirk, SGK Consulting (April 2006)
|
|
|
|
|
|
For many managers, projects are just another task they would rather not have. Often
organisations are not set up with projects in mind – yet if they are going to develop as a
business, they need to successfully undertake projects: new products need to be
launched, new IT systems need to be implemented and new HR policies need to be put
in place.
In an ideal world, managers would be trained in project management skills as part of
their career development and would be equipped to take on these challenges. Sadly, this
is often not the case. So how can you avoid the pitfalls and get that project completed,
without the benefit of classic project management expertise?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Look for the label: Donnie MacNicol, Team Animation (March 2006)
|
|
|
|
|
|
The accumulated wisdom of traditional project management provides the basis for
winning the ‘minds’ of team members. This ensures that people understand what needs
to be achieved, how it must be achieved and the part they can play in making it happen.
Winning ‘hearts’ is achieved by creating a project which people can believe in, have a
relationship with and develop some level of emotional attachment to.
Clearly, without emotional attachment, you will not get the undivided attention and the
complete support of the individual, team or stakeholder group. But why is this important?
The reason is that value can only be created on a project through an individual taking
action – and it is therefore critically important ‘how’ that person takes that action. For
example, it might be the speed and care with which a bricklayer lays a wall, the
consideration and time an information architect gives to a particular design, or the extra effort a financial controller
makes in reviewing aspects of the budget prior to sign-off. The quality of each action, cumulatively, will decide between
a project being a success or failure. If your direct and wider team are truly engaged, they will feel part of something that
deserves their best, not just what has been contracted for.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Getting an assurance policy: John Brinkworth, Serco Consulting (February 2006)
|
|
|
|
|
|
The media regularly report that projects continue to run into problems and do not always
deliver as expected. Surveys claim that between 50% and 70% of IT projects fail to
some degree. This is surprising and concerning, since good practice for project
management is well-defined and well-documented. People involved in project
governance are faced with the serious challenge of how to reduce the chances of their
projects running into trouble. ‘Project assurance’ can be the answer.
How can you tell the difference between good and bad project assurance? The first can
help to improve the chances of a successful outcome; the latter is likely to simply impose
more bureaucracy without improving your delivery chances. There are a number of key
activities that typify good project assurance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Putting the management back into PM: Alex Robertson, Carosoft (January 2006)
|
|
|
|
|
|
Not too long ago, television viewers in Scotland were favoured with a nightly master
class in project management. Or, to be more accurate, in NOT project management. The
source of this class was the TV report of that day’s proceedings of the Fraser Enquiry
into the building of the new Scottish Parliament. A project originally estimated at a price
of £40 million was finally finished, years late, and 10 times over budget. And night after
night we saw the enquiry conducting a forensic examination of why it happened.
I will spare you the details, but it was very clear from early on that methodologies,
reviews, client committees, no end of scrutiny of schedules and costs aside, there was
little or no professional project management applied, as project scope not so much crept
as galloped out of sight. Civil servants, pressed to be project managers, succeeded one after another, and each one left
a bigger shambles than the previous one. The miracle is that the project was completed at all.
|
|
|
|
|
|
|
|
|
|
| |
|
|
|