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?