Posts Tagged PRINCE2

What makes an excellent project manager?

 

I am exploring the topic of what makes an excellent project manager, potentially for an article on this blog.

Is it knowledge? Character? Experience?

Thoughts and suggestions at any level of detail and however factual or intuitive are welcome!

To participate in this discussion please join me on LinkedIn (http://www.linkedin.com/in/lukeandreski), email me (la[at]andreskisolutions[dot]com) or add your comments below.

Advertisements

, , , , , , , ,

Leave a comment

An Exciting Article On Project Filing

 

In giving this article the title I have given it I might be accused of miss-selling… however, and quite unexpectedly, I find myself, if not exactly excited by, then at least seriously interested in, the topic of project filing.

A significant element of any project manager’s work is to collate, create, review and update documents which relate to the project or projects in hand. For this reason it is important that project documents are filed in an intuitive and sensible way, reflecting both the project management methodology being used and the life cycle to which the project adheres.

Currently I prefer to work with the Project Management Institute’s ‘Project Management Body Of Knowledge’(PMBOK) methodology, with its nine knowledge areas: Scope, Integration, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement. These need to interface with the typical life cycle of the projects with which I am currently involved: initiation; planning; analysis and design; system configuration; data migration; testing, documentation and the transition to operational live running. Then of course there are the pragmatic considerations of information storage and retrieval: What do you need immediate access to as soon as you open a project file? What folders will you need to access most often? Are there other areas of documentation or data which are not covered by the matrix of knowledge areas vs. life cycle? How can you ensure your file structure is intuitive and easy to adopt?

With all this in mind I have devised a project file and folder structure for use with both hardcopy and electronic filing which I have tested against the storage requirements of real project data.

This structure seems to me to work… but is it the best?

Take a look:

The Project File

Folder 1: Stakeholders and Contacts

This folder will include simple contact lists as well as stakeholder analysis and stakeholder management planning

Folder 2: Governance – Charter and Scope

This folder will include the contract, initial scoping documents or terms of reference, the project initiation document or charter, and any further detailed scoping. In other words, all the documents by which the project is initially defined

Folder 3: Project Planning

Once you have established the scope of your project – the objectives, requirements, outline timescales and budget – serious planning can commence, and this folder should contain not only the usual MSP Gantt charts but also meta-planning documents such as your plans for project management,  for quality assurance, for human resource management, for communications and so on

Folder 4: Status – Activities Issues and Risks

To include status reports and updates, issue logs, risk logs and schedule variance

Folder 5: Status – Costs

This folder will include budget or project costs and utilisation reports, and earned value or other assessments of value achieved versus expected. The utilisation of third party deliverables should also be reflected here. This area is given a folder in its own right to reflect the importance of cost within most organisations

Folder 6: Change Control

To hold change requests, both pending and authorised. These, in conjunction with the data held in the Governance folder, define the project

Folder 7: Project Coordination

This folder holds the ‘project office’ type of documentation not already covered by the other folders: the agendas, papers and minutes for formal meetings(such as Board and Project Team meetings). Also documentation related to supplier management or the administration of supplier deliverables such as training and consultancy

Folder 8: Project Data

This folder holds the data associated with the life cycle of your particular type of project, e.g.

8.1   Analysis and Design

8.2   Infrastructure and system administration

8.3   System configuration and build

8.4   Data migration

8.5   Testing and quality control

8.6  Procedures, manuals and guides

Folder 9: Phase and Project Closure

To hold documentation relating to the closure of phases or the project as a whole, including the documentation of lessons to be learned

Folder 10: Miscellaneous

…because there will always be some documents which are impossible to categorise or which do not deserve a category of their own.

This is how I have begun to structure my project files. How have you structured yours?

Luke Andreski PMI PMP

https://andreskiprojectmanagement.wordpress.com/

www.andreskisolutions.com

I am a project manager with many years’ experience in HR and Payroll system implementations. I am in the process of completing my most recent contract for the housing and care organisation Midland Heart. After a one or two month break I will be seeking a new contract from August/September 2013 onward.

, , , , , , , , , , , ,

Leave a comment

Getting System Implementations Right

The challenge

Implementing HR and Payroll systems is a precarious business. Whether you are looking at e-recruitment, training systems, core HR and Payroll, document management, workflow, P11D, talent management or self service solutions, the business environment in which your implementation will take place is complex, evolving, effected by organisational ethos and constantly striving for synergy between the employees’ needs and those of the employing organisation. Throw into this heady mix the divergent temperaments of technologically astute system developers and payroll- or people-focussed system users and the implementation of new software can be quite a challenge…

This is a challenge, however, which offers considerable rewards.

 

The reward

Successful ERP, HR and Payroll implementations can offer:

–          improved organisational morale;

–          increased employee engagement with the processes and objectives of their employer;

–          a shift in the focus of talented staff from admin to strategy;

–          consolidated management information;

–          devolved and more timely input of data;

–          improved business processes;

–          more effective workflow

–          etc

But what is the trick to realising these benefits? What are the ingredients needed to get your system implementation right?

 

A contract that works

A decisive starting point for your implementation is a well formulated contract with the supplier. Useful features of such contracts include:

–          SMART delivery targets

–          A detailed and binding confirmation by your supplier of the extent to which they can meet each and every requirement in your ITT

–          A supplier-incentivising payment profile

–          Penalties for non-performance

–          Defined implementation consultancy and support

–          An agreed change control procedure; and

–          Clear lines of escalation…

If your contract is cursory, vague or simply inadequate, as software and services contracts often are, then you must make sure your project begins with the development of a detailed project charter or Project Initiation Document which both you and your supplier sign up to before work begins. Then, whether you have in your possession a good contract or a good Project Initiation Document, you should keep this in your back pocket at all times – and be ready to call on it at a moment’s notice.

It is essential to ‘work your contract’, making sure your agreed objectives are met and the promised deliverables delivered. This means keeping a tight rein on change control, documenting even honeymoon lapses in supplier performance, and ensuring your supplier is always aware that you expect them to meet both the letter and the spirit of your initial agreement.

 

Manage your supplier

As the saying goes, keep your friends close but your supplier closer. Throughout any software or service implementation it is important to insist on high level supplier representation at Performance Reviews, Steering Group and Project Board meetings. Your supplier’s representatives will far rather get it right, or fix it quick, than explain, face to face, why they got it wrong!

It is important that you own your project’s deliverables; and it is equally important, if your contract permits this, that you maintain some degree of payment leverage. For most suppliers the bottom line is the bottom line. If at all possible, you need to be able to maintain financial leverage up to the last possible moment, otherwise you will find, once the bulk of your payment has arrived in your supplier’s bank account, that their interest in your project rapidly diminishes.

 

Rigorous project management

Of equal importance to supplier management is the management of your own organisation. No matter how tempting it may be, organisations must avoid improving upon their original objectives. Stick to the initial scope of the project and you are far more likely to end up with demonstrable success.

Your project manager must manage your internal stakeholders, keep them informed, and ensure that all those departments or teams effected by your project also recognise their responsibilities towards it. Similarly, your project sponsor must ensure executive level participation, and publicise the executive level commitment to the project.

Communication at all levels is a key ingredient of successful projects.

A strong project team

Your project team will be central to your implementation… and should include:

–          Senior members of the effected departments empowered to make system set-up or business process decisions without recourse to committee

–          Hands-on team members to undertake the non-strategic work; and

–          Supplier-provided consultancy with in-depth knowledge of the system and its implementation.

At various points in the implementation you may also wish to include in the team:

–          Business process analysis and re-engineering expertise

–          An expert on documenting the use of the system

–          Trainers

–          Dedicated resource for project communications; and

–          Super-users who participate in pilot and parallel running.

Further recommendations in regard to the project team are:

–          That core membership of the project team should be dedicated to the project full time

–          That nominated individuals continue to work with the system after project completion, thus benefitting the organisation with the expertise gained during the project; and

–          That a discrete project area is provided for the duration of the project.

A project board or committee should also be convened, inclusive of executive-level representation, senior management from the areas affected (including IT),  and a nominated project sponsor.

 

Other key factors of successful projects

Further recommendations towards ensuring project success:

–          Purchase sufficient expert consultancy for your project, but emphasise skills transfer from consultants to employed staff during the implementation period;

–          Purchase sufficient system training, and also plan for in-house, cascade training where required;

–          Work to a plan and change control any deviation from it;

–          Develop test scripts and test rigorously;

–          Phase your implementation, allowing time to get each phase right;

–          Include pilot or parallel running in any project;

–          Educate stakeholders to expect a productivity dip after system implementation, as the new processes bed-in and familiarity with the system is acquired;

–          Engage with other organisations who use the new system; and

–          Encourage the project team and stakeholders to enjoy and take pride in the project… It’s not every day that you get new toys or the chance to learn new things!

 

A Challenge Successfully Met

I hope these suggestions and tips offer some little guidance toward ensuring that your system implementation is a successful one. If you have other recommendations for increasing the success of ERP, HR or Payroll projects please get in touch via my blog.

In summary, within complex and forward-looking business environments the roll-out of new software or services is a major challenge… but it is a challenge which your organisation can, with a little planning and foresight, successfully and rewardingly meet.

 

Luke Andreski PMI PMP

https://andreskiprojectmanagement.wordpress.com/

www.andreskisolutions.com

 

A version of this article appeared in the respected Digby Morgan Newsletter, Human Resourcefulness

© 2013 Luke Andreski. All rights reserved.

, , , , , , , , , , , , , ,

1 Comment

Prerequisites For Successful HR and Payroll System Implementations

Introduction

Before an HR or Payroll system implementation can begin, a number of important activities must already be underway or drawing to a close. This post briefly looks at the following:

  • The decommissioning of the existing system
  • The procurement of a new system
  • The opportunity for a business process review
  • Other important ‘up front’ success factors.

Decommissioning The Current System

The decommissioning of the current HR and Payroll system can be considered a project in itself. This project should include:

  • A review of the current system’s strengths and weaknesses
  • An analysis of how the system’s weaknesses may be addressed by a new system
  • Consultation with champions of the current system, if there are any, to ensure buy-in for system change (i.e. the initial stages of change management)
  • A cost/benefit justification for moving from the current system; and
  • Decisions on which current system data should be deleted, which should be archived and which data should be cleansed for loading onto the new system. It is best practice within system transitions for the new system be populated only with data that has been checked for accuracy, coherence and integrity. It is also crucial for the implementation of the new system that close attention is given to – and time allowed for – the data mapping process.

The analytical outputs from the decommissioning exercise will feed into the procurement process for the new system and into the initiation and planning stages of the implementation project.

The decommissioning of the current system may be dealt with as a subproject of the implementation project, but it should nevertheless be undertaken rigorously, with the activities described above commenced well in advance of acquiring the new system.

System Procurement

The procurement project will have outputs of central importance to the implementation project. These outputs should include:

  • The initial business case for the system transition, which may feed from the decommissioning exercise
  • A Schedule Of Work or detailed definition of the requirements which the new system and its supplier must meet
  • A contract which includes:
    • Delivery targets
    • Implementation timescales
    • The supplier’s detailed confirmation of the extent to which they can meet each individual requirement in the SOW
    • A supplier-incentivising payment profile
    • Penalties for supplier non-performance
    • Insurance against subcontractor non-performance
    • Defined implementation consultancy and support
    • Defined system and DBA training
    • A detailed Support SLA including escalation points
    • System performance guarantees
    • An agreed change control procedure
    • A supplier/client conflict resolution strategy
  • The purchased software, hardware, database environments, comms, services and implementation support.

It is essential, in addition to the organisation’s procurement team and representatives from IT, that both senior and junior HR and Payroll users are engaged in the selection process. Representation should also be sought from other important stakeholders, such as Finance, Audit and the employees themselves.

Business Process Review

An opportunity which should not be missed when taking on a new HR and Payroll system is that of reviewing the efficacy and cost-effectiveness of the business processes being supported by the system. The business process review should cover:

  • Document and data flows
  • Authorisation processes
  • The practices, codes and calculations used in areas such as absence recording
  • System-related HR processes and procedures in general
  • Departmental boundaries and responsibilities – and whether these should be modified in light of the capabilities of the new system
  • The data required by the organisation and who should have access to that data
  • The standardisation of data formats and codifications throughout the organisation; and
  • Whether all the reports currently generated are needed and what new reports might be required.

Other Important Success Factors

Other precursors to a successful HR and Payroll system implementation include:

  • Commitment to system change by management at an executive level
  • A recognition of the size and complexity of the forthcoming project. HR and Payroll implementations can range in duration from four months for a small company with straightforward pay and employment conditions to nine months for companies with employee numbers in the low thousands… through to twenty-four months for very large organisations taking a phased implementation approach
  • Detailed, up front project evaluation and planning
  • A financial commitment recognising the many factors of a system change of this sort, inclusive of:
    • Hardware, software and comms
    • Project management
    • Expert consultancy
    • Training consultancy
    • Project staff
    • Time taken from HR, Payroll and Finance staff for initial consultations through to testing and parallel running; and
    • Temporary productivity reduction whilst familiarity is gained with the new processes and system.

For an extended discussion of the key features of successful HR and Payroll implementations, please see the document ‘Best Practice for HR and Payroll System Implementations’ on this blog.

Conclusion

Implementing a new HR and Payroll system does not begin when system access is first provided to the project team – or even with the signing of the contract for the new system. A rigorous procurement exercise must first take place, and this should be supported by analysis of the reasons for change, the production of a compelling business case, the production of a comprehensive requirements document and some anticipatory change management.

Undertake these activities and your implementation should get off to a running start.

Luke Andreski

www.andreskisolutions.com

©  Luke Andreski 2012. All rights reserved

Comments and feedback welcome!

 

, , , , , , , , , , , ,

1 Comment

The Perfect Plan

 

Two fundamental principles which underlie project management methodologies such as PMBOK and PRINCE2 are:

Look before you leap

and

Learn from when you fell.

These principles are elaborated into complex project management ‘envelopes’ surrounding what might be thought of as the delivery activities of the project – the aim being to ensure that these activities are accomplished successfully.

On this basis, I would suggest that the following list details the ideal project management envelope, into which the considerably more detailed delivery elements of any project can be inserted.

Project Assessment

Preliminary meetings

Determine project authority and status

Confirm Project Brief

Authorise Project Initiation

Project Initiation

Initiation Kick-off

Review Project Brief, Bus. Case, Contract, SOW

Identify existing processes and standards

Review political / organisational environment

Stakeholder Interviews and Analysis

Stakeholder analysis

Stakeholder interviews

Produce stakeholder list

Identify and Coordinate Project Initiation and Planning Resource

Agree Resource Reqs for Initiation and Planning Phase

Acquire Resource

Administer Resource

Develop, Sign-off and Publish Project Charter

Develop project charter

Publish draft project charter

Project charter review

Sign-off project charter

Finalise project charter

Sign-off project charter

Project Launch

Plan project kick-off

Project kick-off meeting

Project Planning

Develop Outline Project Management Plan

Project Requirements – Detailed Definition

Develop, Sign Off and Publish Detailed Scope Document

Develop Detailed Project Scope Document

Review Detailed Project Scope

Sign Off Detailed Project Scope

Publish Detailed Project Scope

Develop Work Breakdown Structure

Develop work Breakdown Dictionary

Develop, Sign-off and Publish Detailed Project Plans

Develop Project Schedule

Define Activities

Sequence Activities

Estimate Resource

Estimate Duration

Develop Project Schedule

Estimate Costs and Confirm Budget

Develop Human Resource Plan

Develop Communications Plan

Develop Project Risk Management Plan

Identify Initial Project Risks

Assess and Prioritise Risks

Develop Risk Response Proposals

Develop Risk Management Plan

Review Project Plans

Sign Off Detailed Project Plan

Publish Detailed Project Plan

      

Execute Project Phase 1

Establish Team and Infrastructure

Acquire Full Project Team

Set Up Team Infrastructure

Develop Team

Manage Team

Phase 1 Activities and Deliverables

Perform Work Activity 1

Deliver Work Activity 1 Result

Perform Work Activity n

Deliver Work Activity n Result

Phase 1 Monitoring and Control

Monitor / Control Activities 1 – n

Verify Scope of Activities 1 – n

Control Phase 1 Quality

Control Schedule and Costs

Control Risks

Close Phase 1

Lessons Learnt Meeting

Document Lessons Learnt

Update Project Documents

Sign Off Phase 1 / Authorise Phase 2

Execute Project Phases 1 + n

  

Project Closedown

Lessons Learnt Meeting

Document Lessons Learnt

Contracts Closure

Administrative Closure

The central purpose of all of this detail is to support the key delivery activities. The supposition of project management methodologies such as PRINCE2 and PMBOK is that phases 1 through 1+n will be delivered successfully – on time, on budget and ‘to spec’ – if a framework along the lines detailed above is rigorously applied. This is something with which I largely agree. However, a further and, I believe, utterly crucial requirement for project success is this: no project will be successful without enthusiasm for change, a powerful commitment to the project objectives, and a concern for the people involved in the project and affected by it.

Luke Andreski

www.andreskisolutions.com

© Luke Andreski2012. All rights reserved.

, , , , , , , , ,

Leave a comment

Agile, PRINCE2 and PMBOK

Introduction

This post briefly reviews the similarities and differences between PRINCE2, PMBOK and Agile, and suggests that best practice can be derived from elements within all three methodologies.

The Similarities

PMBOK and PRINCE/PRINCE2 are project management methodologies; Agile is a software development methodology that can be applied to some projects.

Similarities between all three methods are:

  •  They each provide a set of tools, techniques and templates for managing projects – avoiding the need for re-invention.
  • They each aim at tackling common and problematic project characteristics:

–          Accelerated change

–          New or unique deliverables

–          Limitations on resource or budget

–          Delineated timescales.

  • All three methods seek to reduce the risks inherent in undertaking projects: unsatisfactory deliverables; overspend; schedule slippage.

Key Differences

PMBOK and PRINCE2 are similar in offering a highly structured template for project administration and control. They differ in that:

  • PRINCE2 is more prescriptive in terms of project management outputs: e.g. baseline documents; configuration records and logs; reports.
  • PMBOK offers more guidance on the tools to be used: e.g. earned value analysis; three-point estimates; stakeholder matrices; information gathering techniques.
  • PRINCE2 emphasises the need to regularly review the business case for the project. PMBOK assumes that the business case is external to the project, once the project has been initiated, and that it is not in the control of the project manager.
  • PRINCE2 offers guidance for corporate as well as project management whilst PMBOK concentrates on the techniques, tasks and responsibilities of programme or project manager.

Agile offers a very different formula to both these methodologies.

PRINCE2 and PMBOK strongly emphasise the importance of planning, as per Deming’s ‘Plan, Act, Check, Do’ or Boyd’s ‘Observe, Orient, Decide, Act’. Agile, however, works on the assumption that the deliverables may be too complex or unknowable to be planned for up-front. More suitable, perhaps, to smaller projects with multiple deliverables, Agile (or Agile With Scrum) suggests a less formal project structure, with the project manager (or scrum-master) facilitating an iterative process of short development cycles or sprints. Each sprint, which must produce completed deliverables, may be as little as two weeks in length.

The key themes of Agile are: visibility; inspection; adaptation.

Agile can be characterised as encouraging self-micro-management by the individuals involved in performing the work.

Adopting Best Practice

I would suggest that PRINCE2 and PMBOK are on a par in terms of offering structured, detailed and comprehensive project management methodologies. I would favour PMBOK on the basis that it is less prescriptive and therefore more flexible, and to me, at least, PMBOK seems more intuitive: a clear and well thought-out formulation of good practice and common sense.

From both methods I would take forward:

  • Scrupulous planning
  • Rigorous project control
  • Clearly defined roles
  • An emphasis on communication
  • Clear and validated deliverables.

From Agile I would loot:

  • Quick-win deliverables where possible
  • An emphasis on team and individual initiative
  • Protocols for meetings, such as the ‘scrum meeting’ where each project team member has two minute to answer three questions:

–          What have you achieved on this project since the last scrum?

–          What are you planning to achieve by the next?

–          What if anything is preventing you from meeting your commitments to the project?

Conclusion

The PMBOK, PRINCE2 and Agile methodologies have each gained large numbers of practitioners around the world. This is because each offer compelling methods for dealing with the administration and management of projects. It therefore seems likely that best practice will eventually be defined as an adaptive hybrid of all three schools of thought.

Luke Andreski

https://andreskiprojectmanagement.wordpress.com/

www.andreskisolutions.com

Feedback on any of my posts and the issues they discuss is very welcome.

© 2013 Luke Andreski. All rights reserved.

, , , , , , ,

1 Comment