Reducing Your Cost of Quality

By Alan S. Koch, PMP | 24th October 2009

The Cost of Quality is a significant cost on any project so prudent managers look for ways to keep those costs in check.

How high is your Cost of Quality? The answer might surprise you. Yes, it includes reviews, the QA infrastructure, and preparing tests, those are your "Appraisal Costs". But how high are your "Failure Costs" the cost of defects?

Your engineers spend time in diagnosis and rework, development schedules slip, support costs climb, and your company's and products' reputations sink. These Failure Costs, which are the more significant Cost of Quality, are beyond your direct control. But you can gain control over them indirectly, by investing in Appraisal Costs that minimise Failure Costs, reducing your total Cost of Quality and making it more predictable.

Successful Software Development: It's Not Rocket Science

By Duncan Haughey | 21st October 2009

People generally have a misconception that managing software development projects is hard but it's not rocket science.

Sometimes I wonder after years of software development whether things have really changed that much. Sure, technology has moved on at pace, but has our approach to running software development projects.

Users remain baffled by techno speak, developers prefer to invent rather than reuse and know what is best for you before you tell them what you want, while projects frequently miss deadlines and exceed budgets.

Just look at the Ministry of Defence who wasted nearly £30m on two IT projects alone. The first project, a communications system for the RAF, was abandoned because of problems integrating it with other systems and £21m was written off. The second, a pay system for the Navy, was closed when it became clear that the project would cost three times the expected amount of £18.9m. £8.7m had already been spent, this too was written off.¹

Avoiding the common pitfalls of software development is not rocket science; it's simply a case of taking some sensible measures.

Understanding the Software Development Process

By Mark Spenser | 19th October 2009

Avoid the Common Obstacles and Plan for a Successful Project.

The software development process has undergone drastic changes over the years. Initially only requiring a developer to write the code of the software, advances in the industry have expanded development into a more complex process. Involving architects, analysts, programmers, testers and users to develop code, it is now capable of delivering more advanced results. You can avoid some of the most common problems that occur with software development by understanding the three most common reasons for project failure:

  1. Project objectives not fully specified: When undertaking a software development project, it is important to know what your needs and expectations are. What do you want the software to do exactly? A comprehensive approach that envisions the precise outcomes before clearly stating objectives is the way to a successful beginning for a software development project.
  2. Bad planning and estimating: A thorough understanding of the functions that will be needed by end users of the software will determine what its features should be. In addition, the desired integration, exporting, hosting and mobile interface capabilities should be clearly defined. It is important to estimate a budget and timetable that is realistic and in accord with these objectives. Planning for these variables will help ensure that a successful software development project can be completed.
  3. Inadequate or no project management methodology: The importance of the role of project manager in the software development process can not be underestimated. A successful development programme will be difficult to achieve without the right leadership to co-ordinate the many aspects of the project. The project manager will oversee the process, anticipate obstacles, and keep things going on the right track.

Strain Between Release Management (ITIL) and Project Work (PMBOK) - A Case Discussion

By John Ashman | 18th October 2009

This is a discussion of the tension and its mitigation between ITIL Release Management and Application development (projects) and enhancements from a particular real world occurrence.

While working for a major global manufacturing company they elected to re-outsource with a new model in the middle of last year. This was managed in a coherent programme fashion, but of course not all the details could be fleshed out and integrated in advance as they are a huge organisation.

There was a fundamental schism in the re-outsourcing between Services (infrastructure and operations) and Systems (application support and projects for applications). Each side of this schism placed contracts both for the front line performing suppliers, but also for a higher level set of integration services.

On the Services side of course there was bed rock written into the agreements to employ ITIL processes. And of course the integrating supplier on the services side arrived with their own vision and tool(s).

On the Systems side these contracts brought a standard approach to a considerable portion of the legacy application sustain (break / fix) and small enhancements. Vendors were organised by sets of applications the performed a band of business process functions.

However the integration was meant to occur with two layers of vendor, and the over arching did not get to a standard or common approach on application enhancements quickly. As a result different organisations defined by bands of functionality executed somewhat differently for application support.

Mechanics for governing changes were vague, but in the space in which I worked discretionary (not the break / fix) enhancements were set up with service level wording that clearly required their management change by change, item by item. Additionally, more because of history, governance was set up to support the dialogue about when each change could be made with the end user or business partner.

The company was far more standard on macro co-ordination of application projects. There were a set of different cases but all of these were derivatives of a recognisable PMBOK (Project Management Book of Knowledge) approach.

For our purposes I will put projects into two groups. First there were waterfall projects (Plan, Define, Design, Construct, Test, and Deploy) and then there were iterative, or cyclic (RUP) kinds of projects.

© 2015
Designed by Lorelei