Criteria for Creating Project Artefacts

If I take a look at the people I follow on Twitter (currently about 1100) they fall into roughly several main categories listed here but not in any specific order:-

• Process and Quality Experts (including CMMI, ITIL and ISO specialists)
• Apple technical experts (including magazines and developers)
• Apple fanboys and girls
• Business leaders (non-IT)
• Musicians and other "celebrities"
• Journalists
• IT professionals

Out of all the IT professionals, nearly all of them are self proclaimed Agile practitioners, managers or gurus. Why do I mention this? Well mainly because I don't believe that this reflects the real state of the larger world where I suspect the Agile sector is much smaller than the more traditional development approaches. Even within the Agile sector, I suspect there are only a tiny percentage of people "doing Agile properly". Of those who do, most of them seem to spend most of their time on Twitter, so I'm not sure how much they really practice what they preach!

By and large businesses still run fairly old fashioned IT programmes and projects, and very often these projects follow quality management systems that are somewhat over-engineered and overblown. Personally, I think I fit somewhere between the two places - I don't count myself as an Agile practitioner although I was part of the DSDM movement many years ago, and I have an aversion to heavy weight development and management processes and methods.

Even with heavy weight process sets, most standards encourage tailoring of the process and the project documentation so that it aligns with the specific requirements of the project. In other words, you do what is necessary and ignore what is irrelevant. Quality and process 'experts' are on hand to assist the project or programme manager make these 'difficult' decisions, and to help the project team members create the project artefacts that are deemed to be required.

Which brings me on to the real gist of this post, namely that there is something wrong with this approach. If a project manager doesn't know what a specific project artefact or process is all about or cannot make a decision about whether or not a particular artefact should be created or process followed then there should be some serious questions about whether he or she should be managing a project in the first place.

This isn't aimed solely at project managers, but anyone involved in the planning and execution of a project, including developers, testers and business analysts.

For me, there are really only three criteria which should be used to judge whether a project artefact should be created or not.

• Does it add value?
• Will the project be at risk if it is not created?
• Do you know why you are creating it? (because I've been told to is not a valid answer)

If the answer to the last question is no, then the next question should be "Am I the right person to be doing this job?"


 .

8 Quality Principles that everyone should adhere to

At various times in my career to date I've held the role of Quality Manager or Quality Leader either at project, programme or organisational levels. Over the years I've developed a set of eight simple Quality Principles that are easy to understand and more importantly, easy to achieve by everyone in the organisation. In fact these aren't so much Quality Principles as common sense principles which often fly out of the window in times of stress. However, if you follow these principles, and communicate them across the team, department or enterprise you may find that some of the things that cause the problems in the first place will start to disappear. Print them out and post them on your noticeboards, issue all members of staff with a laminated copy to keep on their desks. And make sure that you follow up on them by ensuring that at the very least you yourself adhere to them whatever pressure you find yourself under.

Quality is a collective responsibility

• Everyone must be actively involved
• Your actions and what you produce reflects on all of us

Honour your commitments

• Create a realistic estimate prior to making the commitment and document your assumptions
• Don’t commit to something you know you can’t achieve
• Provide an early warning if you cannot fulfil a commitment you made

Right first time, every time

• If you don’t have time to do it right initially, when will you have time to fix it ?
• Perfection is not a contractual requirement

A second opinion is not optional

• All contractually required deliverables that you create must be reviewed by a person other than yourself
• Allow time for review and rework in your estimates

If in doubt…ask

• No question is stupid if it helps you to do your job, as well as helping others…
• …but use your common sense

If you see something wrong (or know of something better) …tell someone

• All processes can be improved
• We can’t fix things we don’t know about

Plan your meetings

• Make sure you have a clear purpose, a published agenda and the right participants
• Record critical decisions and actions in meeting minutes

Keep It Simple, Stupid (KISS)

• Life is complicated enough – don’t make it any more so

The SPI Manifesto - What's It All About ?

It's election time in the UK, and this week the major parties have all released their manifestos outlining their policies and plans for the next five years should they be elected into government. Earlier this year the SPI Manifesto was published; the work of a group of people who attended a workshop in late 2009 in conjunction with the EuroSPI Conference in Spain. The publication of the manifesto appears to have polarised the SPI community into staunch supporters and those who are rather more sceptical about it. For myself, the manifesto certainly raises more questions than it answers, and in this entry I'll try to explain why. However this is not going to be an in depth analysis of the manifesto - although that may come later!

The Facts The SPI Manifesto is a 17 page pamphlet which is structured as three values and ten supporting principles. The three values are concerned with People, Business and Change, and each consists of a context and problem statement, a section explaining the value and a number of "hints and examples". The values are statements of what the authors truly believe. Four principles support the People value, three support the Business value and a further three support the Change value, and are explained as principles that the authors trust to support the values. Each principle consists of an explanation and an example. The front page summarises the values and principles, followed by an explanation of how the manifesto came into existence and what to use it for, and the final page is given over to the presenters, authors and reviewers.

Manifesto or Manifest ?

The dictionary definition of a manifesto is

"a public declaration of policy and aims, especially one issued before an election by a political party or candidate" 

The word originates from the 1644 Italian word "manifesto" which means a public declaration explaining past actions and announcing the motive for forthcoming ones". My first issue is trying to figure out what this document actually is. It is titled the "SPI Manifesto", but in the description of what it is, it suddenly becomes a manifest which, when used as a noun, is defined as a customs document listing the contents put on a plane or ship. Clearly this isn't one of those! Semantics aside, this is the first of numerous inconsistencies which percolate through the document.

Three Unanswered Questions Despite having read through the document several times and having been in discussions with various knowledgeable colleagues I cannot find the answers to three fundamental questions. Quite simply these are:

• What is the real purpose of the SPI Manifesto ?
• Who are the intended audiences ?
• Why was it thought necessary to create such a manifesto in the first place ?

A basic principle of process improvement teach us that we undertake a change or improvement activity in order to fill a requirement or to meet a need. A second basic principle is to identify the stakeholders impacted by the change or improvement. However, the SPI Manifesto, at no point that I can see, addresses either of these principles. And without these critical issues being addressed, the manifesto is left in a state of limbo. In a real life business environment, such a document would never see the light of day without having a requirement to meet or a defined target audience.

An Academic Exercise ? Given the failure of the manifesto to address the three questions I posed above, can we surmise that the undefined purpose of the document was to purely to complete an academic exercise to see whether such a document could be created? Without wishing to demean the contributors, when I cross-referenced the list on the back page of the manifesto, I wasn't surprised to find the vast majority appeared to be academics rather than practitioners. There is a certain irony in this because the first value regarding People talks about the failure of ivory towers in the drive for successful SPI!

Methinks there may even have been an unstated desire to create something akin to the Agile Manifesto simply because nothing existed in the SPI space. Unfortunately it's probably 20 years too late! It is probably fair to say that most of what is written in the SPI Manifesto is available in standard industry texts on process improvement and change management. It may not be as concise, but it is often written in a more appealing way, better explained and, almost always, with a specified target audience in mind.

Missing the Real Target

When you look around at the attendees of SPI conferences, seminars and SPIN groups, it doesn't take long to realise that most of the attendees are either SPI or Quality consultants or people suddenly faced with the prospect of leading or participating in process improvement initiatives for the first time.

Rarely do you see the CIO, CEO or CFO of an organisation, unless they are sponsors or key notes speakers at the event. In fact it is very rare for any decision making executives to turn out to these events. Clearly, they are busy people and cannot take four days out to attend conference. But these are the very people who we, as an SPI community, should be addressing. If I was a C-Level executive and this came to my attention I'm fairly certain my reaction would be along the lines of "So What?".

The trouble is, even as an experienced consultant and practitioner, my initial reaction to the SPI Manifesto is also pretty much "So What?"...

The Trouble(s) with Software Process Improvement

Fifteen or more years of software process improvement efforts have not lead to the remarkable changes that people like Watts Humphrey may have envisaged when he wrote "Managing the Software Process". The reality is that despite our efforts software development projects continue to fail either completely or to meet their intended budget, time and quality objectives. Even high maturity organisations deliver poor quality software, and the return on investment from quality and other process improvement activities remains low. That’s not to say that SPI has failed and we should give up on it, but if we continue to perform the same actions and fall into the same traps we can expect the same relatively poor results. Even companies that were early adopters of CMM and CMMI and have reached the highest levels of maturity now find themselves struggling to retain their status and suffering the mediocre results of more naïve organisations. Some of the reasons for failure are:

• Insufficient management sponsorship, ownership and responsibility - SPI is viewed as a technical activity and management directives are delegated to groups without sufficient authority to “Just go and do it”
• Software Process Groups lack the discipline and management skills required to undertake improvement projects, with the apparent effect of causing a “Do as I say, not as I do” environment
• Expectations of return are grossly over-exaggerated in an attempt to secure funding, and funding is removed before any real benefits are realised
• Supplier management is poor, and outsourcing suppliers often mismatched against the organisation’s values and beliefs, especially with respect to quality
• Focus on CMMI, maturity levels and specific goals rather than doing what is best and right for an organisation using diverse methods, tools and techniques
• An unmanaged approach to change leading to employee resistance at all levels of the organisation
• Failure to adopt a holistic approach across the organisation, with associated confusion, duplication of effort, and critical activities falling between the cracks
• Decision makers are informed about SPI activities rather than consulted and involved
• Waves of initiatives roll on without pausing to understand the effects of the previous initiatives and often undoing the good that has gone before
• Improvement plans are based on perception rather than fact - data is not used to verify that the right areas are being targeted
• Quality and process teams undermining their own efforts by failing to add genuine value to the organisation and its business

If you pick up any book on process improvement you will see that these and other issues like them have been identified and understood for many years, yet some or all of them still abound in any organisation currently running SPI initiatives. Given that those same books often provide the solutions on how to avoid the problems, I can only assume that there must be something more fundamental going on which is causing the software industry to fail to rise to the challenge, namely the people problems I described in my last post on the 7 Deadly Sins of Process Improvement (or Change Management). Next time I'll describe the first of these - Arrogance.