Monday

Monthly Archives: March 2009

When does a project start and end?

Posted on March 31, 2009 by | Leave a comment

There seems to be an attempt by many senior managers to make their project managers responsible for all aspects of a project from understanding the business need through to realising the benefits years after the project has finished. Whilst this can seem a very effective ‘buck passing’ to blame someone else for another failure, it is hardly fair or reasonable and is highly detrimental to the organisation.

PMI and the new ISO21500 have the view a project starts when it is officially started and it finishes when it has delivered all of the required deliverables. This raises a number of sensible considerations.

Starting a project
Only the managers of an organisation are in a position to determine its strategic direction and then identify and prioritise the ‘needs’ that require meeting to implement the strategy. After a ‘need’ is defined a project can be initiated to deliver the required outputs. This does not mean the business managers need to have a fully defined specification but they must know how much they know about what’s required:

  • If the requirements are clearly understood, a project can be initiated with defined time and cost parameters and limited contingencies.
  • If the requirements need to be defined or clarified, the project needs to be established with success criteria understood, adequate time and cost contingencies in place and a ‘gateway’ process defined to ascertain the ongoing viability of the project as the requirements are progressively firmed up. If the project continues to offer a valuable contribution to the organisation it should continue. If its value drops below an acceptable level it should be terminated at the appropriate gateway review.

The PMBOK® Guide is relatively silent in these areas but there’s plenty of good information available from OGC and the Association for Project Management in the UK.

Finishing a project
Whilst the project manager needs to be aware of the value proposition for the project, to assist in decision making within the project, the project manager can only be responsible for delivering the required outputs optimised to the needs of the organisation. The rest of the value chain is dependent on the organisation’s line managers making effective use of the outputs to change the way the business actually works and instigate positive changes to realise the benefits that create value to the organisation.

For more on this topic see two earlier blogs:
– Value is in the Eye of the Stakeholder
– The Scope of Change

More in a couple of days on understanding the degree of certainty involved in projects.

Leave a comment

Posted in General Project Management, Scope Management

Tagged , , , , , ,

Value is in the eye of the stakeholder

Posted on March 28, 2009 by | 10 comments

The only purpose of undertaking any business activity is to create value! If undertaking the work destroys value the activity should not be started.

The Value Chain

Any value proposition though is ‘in the eye of the stakeholder’ – this is rarely solely constrained by either time or cost. Effective value management requires an understanding of what is valuable to the organisation and the activity to create value should be focused on successfully delivering the anticipated value.

The chain of work starts with a project or similar activity initiated to create a new product, service or result. However, the new output by itself cannot deliver a benefit to the organisation and the project manager cannot be held responsible for the creation of value. The organisation’s management has to make effective use of the output to realise a benefit. It is the organisations management that manages the organisation and these people need to change the way the organisation works to realize the intended benefit. The role of the project team in value creation is to ensure their output has all of the necessary characteristics and components to allow the organisation to easily adopt the ‘new output’ into it’s overall way of working (eg, effective training materials).

The outcome from making effective use of the output is expected to create a benefit – however to realise a benefit, the outcome needs to support a strategic objective of the organisation. If the outcome is in conflict with the organisations strategy, value can still be destroyed. Strategic alignment is not an afterthought! The processes to initiate the project should have as a basic consideration its alignment with the organisations strategic objectives.

Assuming strategic alignment is achieved, the realised benefits should translate into real value. The challenge is often quantifying value – the concept of ‘value drivers’ helps. Value drivers allow the benefit to be quantified either financially or by other less tangible means.

In the current economic climate, organisations are finding operating capital in short supply. Therefore a new process to accelerate the billing cycle can be measured at several levels:

  • The output from the activity to develop the new billing process is simply the new process – this has no value.
  • Once the organisations management starts using the new process the measurable outcome is a reduction in the billing cycle from (say) 45 days to 32 days.
  • The benefit of this reduction in the billing cycle could be a reduction in operating capital needs of $500,000.
  • The value of this reduction is $500,000 at 12% interest = $60,000 per annum.
    The above example may also trigger additional value by allowing the capital to be redeployed into another profit generating activity, improving customer relationships, etc.

Once the whole organisation is aware of the value proposition, decisions to de-scope the initial work to meet time constraints and/or cost constraints can be made sensibly.

  • A decision to de-scope the project to achieve a 2 week saving in time that results in a 6 week longer implementation period (eg, by reducing training development) is clearly counterproductive.
  • Similarly a decision to de-scope the project to avoid a $5,000 cost overrun that changes the reduction in the billing cycle time from 13 days to 6 days will result in a halving of the capital saving and a cost increase to the organisation of $30,000.

The challenge is identifying and communicating the value drivers to all levels of management involved in the activity so that valuable decisions are made in preference to knee jerk gut reactions focused on short term, easy to measure metrics. Value is created by meeting the strategic needs of the organisation’s stakeholders – this requires careful analysis and understanding of who they are and what are their real requirements; ie, effective stakeholder management.

For more ideas on the realisation of value, see the work by Jed Simms at: http://www.valuedeliverymanagement.com/

For more on effective stakeholder management see: http://www.stakeholder-management.com

10 Comments

Posted in Change Management, Stakeholder Management, Value

Tagged , , , , , ,

Revolutionary Scheduling – Boston 2009

Posted on March 27, 2009 by | Leave a comment

Registrations are open for the 6th annual PMI College of Scheduling conference. The conference will be held in Boston, MA from May 17-20, 2009 at the Renaissance Boston Waterfront Hotel. For more information see http://www.pmicosconference.com/

This annual gathering is the preeminent scheduling event of the year with a wide range of speakers, working sessions and networking opportunities. My paper, Research 106 – Scheduling in the Age of Complexity, can be pre-viewed at http://www.mosaicprojects.com.au/Resources_Papers_089.html

More on the conference next month from Boston…..

Leave a comment

Posted in Project Management Conferences, Scheduling

Tagged , , , ,

PMP and CAPM Exam Updates

Posted on March 13, 2009 by | Leave a comment

Most people will be aware PMI launched the 4th Edition of the PMBOK® Guide at the end of December. The PMP exam changes to the new PMBOK on the 1st July and the CAPM exam on the 1st August. Until then, the current exam is based on the old PMBOK® Guide 3rd Edition.

We are in the process of starting the update of our course materials and will be offering our Mentored Email™ courses based on the new PMBOK from the end of March. Most people take 3 or 4 months to work through the self-paced materials so this is it…..

The reason for this blog is to alert everyone to the extent of changes at the detailed level in the new PMBOK. There’s not a huge difference between the 3rd and 4th editions at the macro level but virtually every page has been re-written and improved at the detail level.

This means it is critically important for prospective candidates to pick their exam date, select the right version of the PMBOK and study to achieve their target! There will be a lot of work needed to change horses mid-race. You’ve been warned.

To double check the correct version of the PMBOK® Guide for study based on your planned exam date see the PMI Exam Calculator.

Leave a comment

Posted in Training

Tagged , , , , , , ,

Managing Agile Projects

Posted on March 7, 2009 by | 3 comments

The two earlier blogs in this series focused on what’s NOT project management.

Agile and Waterfall are two different software development methodologies (see: Agile is NOT Project Management)

Operational maintenance with stable teams dealing with new work and maintenance upgrades on an organization wide basis is not project management even if there are new features being added to the IT infrastructure. This type of work is traditional operational management even if scrum and other Agile techniques are being used (see: De-Projectising IT Maintenance)

Traditional IT project management has grown up around and closely aligned with the Waterfall software development methodology. As with most engineering projects the final product to be delivered is scoped, designed, built, tested and implemented – in that order. This is OK if the client knows what it needs precisely and the number of changes is relatively small. Waterfall falls down (pardon the pun) if the project is a quest to achieve an objective and everything changes routinely.

Agile seems to be an ideally suited methodology for developing the software but if the work is also a project how should the PMBOK® Guide processes be applied? This blog will outline some ideas at a high level, later blogs may dig into some areas more deeply.

The PMBOK® Guide 4th Edition (2008) has 8 knowledge areas:

Project Scope Management
Traditional project management expects scope management to define the output. In an Agile project the final outputs should be defined in terms of achieved capabilities, how the capability will be achieved will be discovered along the journey.

This makes ‘Verifying the Scope’ interesting. There needs to be clearly defined way to assess if the capability has been delivered. How do you measure a ‘user friendly interface’? It’s not impossible to do but how it’s done needs to be clearly defined.

Change control is also more challenging, as is configuration management.

Project Time Management
Ideally time should not be an issue if the objective is to achieve a required capability. In reality there are usually deadlines.

In an Agile project, scheduling and workflow become closely aligned. The key requirement is an overall system architecture that defines the sequence modules need to be built in to allow progressive testing and implementation of capability. The software architecture defines the build sequence that defines the schedule.

Scheduling is at a much higher level though. A ‘sprint’ is likely to be a single activity of 1 to 2 weeks duration. The sequencing of the ‘sprints’ and the number of sprints that can operate in parallel define the resource requirements and the project duration.

Project Cost Management
Agile projects have to be based on a cost reimbursable system. One tool designed to include a degree of competition with the ability to properly compensate the contractor for its work is southernSCOPE the methodology requires tenders to bid on a project at a $ per function point rate based on a project description and the estimated number of function points. At the end of the project the same independent person who prepared the initial estimate, re-counts the function points and the price is determined.

Project Quality Management
This is probably easier under Agile; quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Human Resource Management
Basically remains unchanged but the skills of the people needed for an Agile project are likely to be different.

Project Communications Management
The level of trust needed to run a Agile project is much higher than a traditional project. Effective ‘real’ communications in all directions are essential. This is different to producing project reports! More later.

Project Risk Management
Recognize you are on a journey focused on delivering value. Significant time and cost contingencies are needed and should be used to optimize the value of the final product. More later!!

Project Procurement Management
This should not change significantly BUT the procurement process needs to be aligned to what it is buying. Agile works in a collaborative partnering space. In the engineering world these are call Alliance Contracts. Traditional contracts will not support Agile delivery methods.

In conclusion: align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!

3 Comments

Posted in Agile Ideas, IT Project Management

Tagged , , , , , , ,

De-Projectising IT Maintenance

Posted on March 6, 2009 by | 4 comments

Following on from my blog Agile is not PM, another interesting trend is the de-projectizing of IT maintenance. An article on page 25 of the November edition of PMI’s PM Network magazine, ‘Foolish Behavior’ detailed the operation of an IT shop supporting a major business. The shop used stable teams, ‘scrum’ to plan work on a monthly basis and ‘sprints’ to deliver weekly improvements. As far as I can see, the situation described by Mr. Keeler in his article is totally focused on routine operations. Stable teams working on dozens of minor objectives selected on the basis of an organisation wide prioritization is the anthisis of a project. Projects are delivered by temporary teams assembled to work on the unique project deliverable (as described in the Project Charter) and then reassigned to other work as the project closes down.

However, the substantial improvements in customer satisfaction demonstrated by Boreland and the Bank of Queensland demonstrate Scrum and Agile are useful product development and maintenance methodologies for many IT applications. The underlying principles would also be very familiar to the maintenance managers of most large facilities. A stable crew of maintenance workers, familiar with the plant look after the prioritized day-to-day maintenance issues and install minor improvements. This routine working environment only gives way to ‘project management’ when a major outage or change is required. Probably the major difference is traditional maintenance management tends to sit inside a functional organisational structure whereas ‘Agile IT maintenance’ seems to operate best in a matrix/collaborative environment.

Whilst in one sense this is a ‘back-to-the-future’ development, recognising IT as an enabler to achieve business success in the same way a plant is essential to a manufacturing businesses success. And whilst both the IT infrastructure and the ‘plant infrastructure’ need routine maintenance and upgrading; there is a key difference. The enhancement of an IT infrastructure involves far more creativity and offers far more opportunity than plant maintenance. Combine this with the idea of actively involving the users in the development process encourages synergistic improvements.

Whilst this is definitely not ‘project management’ there is definitely an emerging practice that has enormous potential to improve the day-to-day operations of many organisations with a large IT infrastructure. More later…..

4 Comments

Posted in IT Project Management

Tagged , , , , ,

Agile is NOT a Project Management Methodology

Posted on March 5, 2009 by | 30 comments

A range of IT commentators are confusing a product development methodology with project management. Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction project management methodology.

Agile is certainly a useful product development methodology for many IT applications and would probably be extremely useful in other situations such as developing training materials and many business change projects where most of the deliverables are relatively intangible. However this cannot turn it into a project management methodology.

Project management is the process of defining scope, deciding on methodologies, creating teams, and all of the other project management processes defined in the PMBOK® Guide. If agile is chosen as the product development methodology for an IT project it will certainly influence the way the project is planned, resourced and controlled but Agile itself is not ‘project management’. This is no different to the need to plan and execute a building project differently if all of the walls are delivered to site as precast panels compared to having workers build the walls in situ using bricks or blocks. If a project exists, project management is the overall controlling process not the selected work delivery process.

What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion. Project Management is still about delivering optimum value based on a predefined framework of time, cost and output and managing changes within this structure.

It would seem many of the advocates of Agile are actually suggesting abandoning project management in situations where the client cannot really define its requirements and adopting a different form of management where conversations control the process development in a collaborative environment and the overall team’s focus is on achieving a ‘happy outcome’ for everyone. The primary constraint in this space is the resources capacity to deliver ‘sprints’ and the organisation’s budgeting process is focused on paying for a more or less stable team of people working consistently on improving the business’ IT infrastructure to service its operational areas.

This would suggest there are limitations to the traditional ‘project management’ paradigm (and I have always felt PM was a focused form of management – see Project Fact or Fiction from 2002) and the emergence of a different paradigm. If this observation is correct the real focus of discussion should be where PM works best and where the new collaborative ‘agile paradigm’ works best.

Comments are welcome and I will blog more on this idea later!!

30 Comments

Posted in Agile Ideas, IT Project Management

Tagged , , , , , ,