Designing and Building Project Systems

Designing and Building Project Systems About the Presenter ADRIAN WERNY  More than 25 years in engineering & construction  Last 15 years+ planning...
Author: Emery Horn
4 downloads 0 Views 667KB Size
Designing and Building Project Systems

About the Presenter ADRIAN WERNY  More than 25 years in engineering & construction  Last 15 years+ planning and project control specialist   10 years in functional management roles with major 

construction companies and EPCM providers.  Now Project Controls Consultant (Werny Project Services) 

Basis of the Presentation Designing, Building, and  Managing Project Systems. ‐ Adrian Werny 2013

Available for download from:  http://wernyprojects.com.au/portfolio‐view/project‐ controls‐systems‐development‐and‐implementation/

Contents  What is a system?  Why are systems important in project management?  A process for building reliable systems

What is a system? “The structured interaction of tools, people, and  processes to produce a consistent, specific result.”

Why are systems important?  Consistent reviewing processes help with early identification and 

resolution of issues  Provides confidence in the results that are produced  Builds a common understanding within and across teams  Provides a framework for training and capability improvement  Facilitates transfer of people and resources around the organisation   Removes the need for every project to build their own work processes

A Four Step Model Work Process  Support

Operational  Support

Procedures Architecture and Structure Requirements and Philosophy

Design and  Build Phase

Application  Building new systems  Replacing the core tool set in existing systems  Upgrading existing systems  Repairing underperforming systems The process may be quick and ad‐hoc for small systems but may require  substantial cost and effort for large systems implementations. 

Step 1: Building a solid foundation

Work Process  Support Procedures Architecture and Structure Requirements and Philosophy

The Business Context  Project role: 

Owner or client / EPCM or PMC / Supplier or contractor

 Project focus: 

Internal versus external focus

 Project size: 

Mega / large / medium / small 

 Project mix: 

Independent projects / related portfolio of projects

 Project type: 

Services only / services plus capital

 Management type: 

Discrete project teams / Project management office

 Delivery model: 

Contracted / self‐perform / joint venture / alliance

 Business structure: 

Local / national / global

 Project locations: 

Central / local / dispersed / remote locations

 Accountabilities: 

Internal versus external accountabilities

Operating Philosophy High Level Definition Of How The System Will Operate

General Considerations Include:   Scope and relationship to other systems and processes  Ownership of the system and the data  Operational level of detail  Need for accuracy versus timeliness  Continuous live data versus reporting cycle data

Operating Philosophy System Specific: Project Cost Control System        

Relationship to corporate ERP or accounting  system Cost and revenue system (profit and loss) or  cost only? Own actual costs or “for and on behalf of”? Budget development and management  process “Actual cost” or “committed cost” basis of  control? Process for management of funding Process for management of risk and  contingency Need for management of multiple currencies

       

Process for management of foreign exchange  fluctuations Process for management of escalation Analysis, forecasting, and reporting  requirements Requirements for earned value analysis Requirements for time phased data – cash  flow Relationship to procurement and contract  management processes Relationship to time management process Relationship with change management  process

Step 2: Getting the Tools in Place Work Process  Support Procedures Architecture and Structure Requirements and Philosophy

Software Selection Business Context Software  Operating Philosophy

The business context and operating philosophy guide  the software selection and the way it will be used

Selecting Software  Software features: Focus on the business requirements and operating philosophy

 What are the IT operating system requirements?  Purchase and maintenance of licences ‐ single / multi‐user licence cost   What level of support is included with the maintenance?  What level of support is available in the market place (consultants)?  What is the availability of training?  What is the availability of trained users in the market place?

System Interfaces Financial  System Procurement  System

Change  Management

Labour  Control

Cost  Control  System

Progress &  Productivity

Contract  Management

Risk  Management

Schedule

A system must  interact with  other systems in  its environment

Data Flow Across an Interface

Cost  Control  System

Budgets

Contract  Management Commitments Variations Forecast

How much and how often?

Types of Interfaces

Manual

Export / Import

Middleware

Direct Integration

Understanding the Interfaces  What is the primary function of each side of the interface?  What is the current or default form of the interface?  What is the proposed final form of the interface?  What information needs to be exchanged across the interface?  Which system is the master source of that information?  Is the format of the information identical on both sides of the interface?

 How often does the information exchange need to take place? Continuous or periodic?  Who is responsible for the information on each side of the interface?  Who is responsible for the transfer of information across the interface?  What checks, balances and validation need to be in place?

Setting up the Software  Software Installation  User Profiles and Privelidges  Codes and Fields  Templates and Reports  Libraries

Step 3: Setting the Rules Work Process  Support Procedures Architecture and Structure Requirements and Philosophy

Procedures A procedure details what things must be done, when, and by whom for the system to achieve its  objectives without necessarily providing step by step instructions as to how to do it.

Cost Control Procedure: Accruals shall be entered into the cost control system at the end of the reporting period to account for all costs known to have been incurred during the period but not entered as actual costs………

Work Instruction: 

User Guide: 

How to identify, calculate,  and prepare accruals for  entry to the cost control  system

How to enter accruals into  the cost control system

Procedures Should:   Provide the basis for a QA audit of the function. It will be a formal document complete with      

revision history, and review and approval signatures. Clearly separate process overview and general information from requirements to be met. Specify who is responsible for performing specific functions and tasks Focus on the requirements that must be met Focus on the outputs that are required including deliverables and timelines Be a useful guide to the system users as to what work must be done and when, without necessarily providing step by step instruction as to how to do it. Generally be relatively software independent:  

If the system software is changed, with no significant change in operating philosophy, then the changes to the procedure should be relatively minor. If the operating philosophy is changed, with or without changes to the software, then changes to the procedure could be significant.

 Recognise and allow for the size and complexity range of projects that the organisation

undertakes  Not contain detailed work instructions or software operating instructions  Not contain “textbook” or basic theory about the work process

Step 4: Supporting the System Work Process  Support Procedures Architecture and Structure Requirements and Philosophy

Work Instructions “Detailed instructions on how to perform specific functions  in order to meet the requirements of the procedure” Examples:  How to prepare an accrual  How to prepare an estimate for a change order  How to prepare a forecast for a schedule of rates contract

User Guides  Location of the database and how to get access  Security and backing up process  User access levels and profiles  Rules for creation of new projects, codes, and fields  Allowable values and data format for specific fields  Location and use of data libraries  The key strokes and mouse clicks required to perform

specific functions

Templates, Samples, Libraries  Guide the user to comply with the procedure  Help to reproduce “best practice”  Reduce set up and data input time  Produce a common set of reports  Provide easy access to necessary information

Training and Training Materials Consider training in three distinct segments:  Fundamentals (core competencies)  Software  Work Processes

Support Structure  Super‐users: System experts who are able to assist users with typical

problems and issues encountered. Super‐users will have a high degree of proficiency and experience with the system.  Administrators: People who are authorised to make changes to the

system or changes to the user access profiles.  Help Line: Phone number that will always to direct to an administrator

or super‐user.  On‐line help form: Email form that will always direct to an

administrator or super‐user.

Collaboration  Single location for all system documentation  Feeling of involvement leading to improved motivation and engagement  Sharing best practice, new ideas and developments, and lessons learned  Place for users to find solutions to common problems and develop their skills  A way for super‐users and administrators to communicate with the user group

COMMUNITY OF PRACTICE

USER GROUP

Implementation Plan 

Communication is critical. Have a communication plan for all stakeholders not just the users



Have a software testing plan including the software setup, configuration and interfaces



Ensure user training covers the system as a whole not just the software operation



Have a process for rectifying problems and supporting users



Have a plan for loading the initial data or transitioning data from existing systems



Consider a pilot project or small group of projects before extending to the whole organisation



Consider whether to (and how to) transition existing legacy projects into the new system



Consider whether to bring in all the features of the new system at once or take a phased approach



Have a plan to complete any outstanding documentation required to complete the system

Summary Work Process Support Support User Guides

Work Instructions Templates

Training Collaboration

Procedures Who

What

When

Architecture and Structure Interfaces

Software

Configuration

Requirements and Philosophy Business Requirements

Operating Philosophy

Questions?