5 methods session 2 webinar slideshare systems co

Editor's Notes

• #5: Managing Director of Systems & Co - a specialist systems consultancy serving clients in the engineering and construction sector. I’ve spent my career in engineering and construction and before Systems & Co I was with Australian tier-one engineering contractor John Holland for a decade. Systems Mgr, Info Mgr, Project Mgr, then corporate roles as Grp Mgr External Applications, Grp Mgr Data & Commercial Involved with projects all over Australia (every capital city at least once) Road, rail, tunneling, water, pipeline, bridge, plus a few building projects Variety of contract models – construct only, managing contractor, alliance, joint venture, GC of D&C, PPP – DBOM and BOOT Small rolling “minor works” of a few A$m to multi-billion dollar mega projects Eastlink (motorway in Melbourne) A$2.5b, Sydney Desalination Plant A$1b, Horizon Alliance, South Rd Superway, Perth Children’s Hospital With this experience I had a good overview of the industry, saw that everybody struggled with information systems (real activity of our industry) CIO ADVISORY & STRATEGY BUSINESS INTELLIGENCE & ANALYTICS DIGITAL BUSINESS IT PROJECT DELIVERY IT COMMERCIAL MANAGEMENT *** Key philosophies? *** I’m going to be speaking about infrastructure projects and contrasting them with building projects to highlight their unique challenges. I’ll be speaking in general terms about projects and best practice and then later on discussing Aconex specifically. Giving a customer perspective … experiences and successes … and then putting particular focus on the new Packages module. Which is highly relevant to infrastructure projects but not yet well know – I imagine that many of you wouldn’t have seen it yet.
• #6: Contrast infrastructure projects with building projects Highlight common challenges and suggest solutions As common problems there are well-worn Diversity Infrastructure projects vary considerably (unlike building projects where complete similar tasks, similar sequence, similar systems, similar roles) Makes standardizing difficult. Can’t run every project the same way. Or use same systems the same way. Cookie cutter won’t cut it. Flexible standardization – e.g. company-wide minimum standards but project flexibility in implementations/configuration etc. or a default with option to adapt. Partnerships Common for infrastructure projects (esp. mega-projects) to be delivered in joint venture or alliance Another reason standardization is difficult. Company A standard? Company B standard? Non-standard compromise? Again flexible standardization. Plus open systems. Allow systems from all partner orgs to work together? Cohesive suite. Or even connect. API. Government Bureaucracy heavy, competing agendas, possibly infrequent activity for a smaller government authority. New to them. Provide structure. Clarity. Explain downstream consequences before asking for a decision. Educate. Complexity Speaks for self. Nuclear reactor vessel, billion dollar metro system, desalination plant, more complex than an apartment building. Some infrastructure projects with high technical complexity borrowing systems engineering techniques from aerospace sector. Structured processes and systems. Opposite end of the spectrum to email free-for-all and spreadsheet anarchy. Ensure can handle vast amounts of data Scale Infrastructure mega-projects are enormous. Thousands of people. Layers of management and abstraction. Infrastructure programs made of multiple projects. Numerous interfaces and interdependencies. Solution is to divide and conquer. Packaging is a perfect example of this approach. Anything that can be Infrastructure specific and or innovative would be helpful. We are doing 2 sessions of this webinar and this session is for the more tech mature audience, so having the angle of maximizing Tech investment would be great. Setting company-wide standards, but meeting project specific requirements Matching project-wide systems with the essential collaborative leadership and team, essential to deliver the highest quality on today’s large infra projects Gaining public trust and support through transparency / visibility Managing and utilizing the vast amount of data Managing the many projects / pieces which are part of large infra programmes High level challenges may include: Lack of transparency into program correspondence, risk, progress. Control and visibility to processes. Compliance and accountability across the entire project team. A single view of project progress across a portfolio of projects. Incomplete or inaccurate handover process. Results in: project delays, cost & schedule overruns, more resources spent on non-compliance, and litigation. What are the Solutions? How have these challenges been resolved.
• #7: CHALLENGE 1: DIVERSITY and FLEXIBLE CONFIGURATION Speaking of configuration … it’s worth mentioning A degree of standardisation across projects is desirable Easier to transition b/w … pick up the processes of a new project … institute common culture or best practice But given the immense variablility of infrastructure projects … scale, engineering discipline, geography, contract form, partners orgs I tend to advise multi-tiered standardisation Universal Project-type (not business unit) Project-specific (customisation) Unconscious standardisation Common baseline or starting point Less “enforce” than “default” Advanced configuration invisible Complexity is behind the scenes Used to make life simple for the user Minimal or no knowledge of company procedures or project-specific processes To the user the system “just works that way”
• #8: Firm believer in configurable platforms – particularly in the world of infrastructure mega-projects where off-the shelf won’t do However, I don’t believe in a free-for-all. In addition to a tiered standardisation approach I recommend minimising complexity for users. Sophisticated configuration behind the scenes But should be simple and intuitive for the user. Configure the platform to guide the user towards the correct process. While products like Aconex are nearly infinitely configurable … show restraint Resist the urge to configure 100-step workflows. Sophisticated configuration Advanced configuration invisible
• #9: CHALLENGE 2: PARTNERSHIPS and a COMMON AND OPEN SYSTEM TIP 1: Implement a common collaboration platform (Aconex) If each collaborator only utilises their own internal systems … Barrier to communication, collaboration Double-handling … work in one system, copy/past or upload into another … delay Difficult viewing all docs or communication in one place Hard to get a complete and clear picture (planning, coordination, dispute, claims etc.) Common communication and collaboration platform Complete and trusted audit trail (provided by a neutral platform) So accustomed to it that I take it for granted Haven’t worked on an infrastructure project without a collab project for a decade Generally accepted and in step with modern collaborative contracting mindset
• #10: Cont … COMMON and OPEN SYSTEM TIP 2: Implement Aconex at the very beginning of the project Implement project systems as soon as possible Particularly true for collaboration system (common platform) How early? Bid or earlier. Full history … knowledge transfer … More effective than handover workshops and launch workshops etc. Visibility of commitments made, dates discussed, designs exchanged, The early phases can be the most collaborative Where the ability to conveniently communicate and collaborate will have the greatest impact on project outcome The sooner in the project lifecycle the smoother it will be Opportunity to capture attention of senior decision-makers and key users before project ramps up
• #11: Cont … COMMON and OPEN SYSTEM By OPEN systems I don’t just anyone can log in. I don’t mean INSECURE I mean systems which are able to TALK TO ONE ANOTHER. To SECURELY EXCHANGE INFORMATION. No project uses a single system. Finance or GL Payroll People/HR (probably multiple – transactional HR, talent mgmt, perf mgmt, learning and devel, eLearning etc.) Program Cost Planning Work Planning or Ops Quality Completions Collaboration Design Mgmt No system is an island Particularly true of PARTNERSHIP projects – joint venture and alliances
• #12: GOVERNMENT and STRUCTURE, EDUCATION, CLARITY Dealing with (or working within) government is different to private industry I mention this because it’s not something that comes up in the building world Very common in the infrastructure world. I’ll be brief. Two challenges government clients deal with BUREAUCRACY AND POLITICS (part of a large department or ministry, not just internal politics but actual politics politics, no single overriding objective) INFREQUENT (the government body might not perform this task very often – their staff are unfamiliar, unsure of process, may not be a process) Acknowledge these challenges and help minimise them Provide structure by agreeing to processes ahead of time Configure those processes into the common platform (convenient and intuitive) Provide training, support, close engagement etc Provide very clear data and establish transparent processes Set realistic timeframes for decisions (govt typically slower to make commercial decisions)
• #13: TIP 4: Divide and Conquer Lot less variation on the Building world But in Infrastructure there can be huge variations in project scale Largest project I’ve been involved with is 10,000 x larger than the smallest Sub-$1m and Plus-$10b. Complexity Difficulty standardising processes (more later) Systems that work for million dollar projects that also work for billion … Those billion dollar mega projects have other complications Larger numbers of stakeholders, layers of management that don’t exist on smaller jobs Higher degrees of engineering complexity, global delivery teams, joint ventures etc. The obvious solution is to divide and conquer. Divide and conquer at multiple levels (clients break into a program of projects) Within a project packages can be a vehicle for that divide and conquer appoach
• #14: New packages module in Aconex is MADE for INFRASTRUCTURE projects Group documents together into a bundle – a package Much easier to manage 250 design packages than 10,000 documents Reduce complexity by a couple of orders of magnitude (to the extent Keep track in your head) Difficult to fully convey the effect that can have on a project Eastlink – six months ahead of schedule and under budget Along with a good team, healthy bid, and drought, design managers credited a substantial portion of that to the use of design packages So while using the packages module in Aconex can reduce the amount of clicking The real benefit is in reducing management complexity, administrative complexity, and cutting weeks off the program. Incredibly convenient and simple but powerful concept
• #15: I imagine that those of you who have some experience or expertise with Aconex Might be wondering what the new Packages module does that we couldn’t do previously Didn’t it already do packages? Well, the new PACKAGES module is exactly that – a register of packages In addition to the register of documents Each package is revision and version controlled And here’s the powerful part - PACKAGES can be put through workflows Meaning that they can be a way of handling documents in bulk No longer necessary to track or manage 10,000 individual docs Just 250 packages. For mind-bogglingly complex to manageable Docs can be in multiple package, and packages of different types. Brings us to the next slide …
• #16: I imagine that those of you who have some experience or expertise with Aconex Might be wondering what the new Packages module does that we couldn’t do previously Didn’t it already do packages? Well, the new PACKAGES module is exactly that – a register of packages In addition to the register of documents Each package is revision and version controlled And here’s the powerful part - PACKAGES can be put through workflows Meaning that they can be a way of handling documents in bulk No longer necessary to track or manage 10,000 individual docs Just 250 packages. For mind-bogglingly complex to manageable Docs can be in multiple package, and packages of different types. Brings us to the next slide …
• #17: Traditional Package types … where we are accustomed to the term Package being used Particularly design packages … very common approach and very effective (but awkward to implement in some systems) But the Packages module in Aconex can also be used for other package types WAPs/SAPs/CAPs … Work Activity Pack, Site, Construction Essentially a bundle of documents presented to the project engineer responsible for delivering a piece of work When I started in the industry they were sometimes on paper – an admin would go through the relevant systems and print out all the documentation related to that piece of work and prepare a thick binder to hand over to the project engineer – Design Drawings, Design Reports, Engineering Standards, Schedules, Change Notes, Subcontracts, ITPs, Contact Lists, etc. Everything the engineer should need to deliver the work. Can do the same in Aconex now. Entirely digital. Imagine being able to pull up all the documents you need by clicking on a single package. Compare that with pecking through a document register trying to find the fifty documents you care about amongst 100,000 others. Similar for work lots. Input vs Output. Completions. Progressive completion. Avoid delays and surprises at PC.
• #18: TIP 3: Utilise your project data Lots of data available. Fully exploit it. Become “data-driven”. Systems & Co currently working with a government infrastructure authority Implementing a business intelligence and management reporting solution Significant undertaking but will move them off spreadsheet-based reporting Significant impact on internal transparency, trend identification, ability to focus attention on emerging issues Same opportunities available to many organisations in our industry.
• #19: CONCLUSION: We’ve covered a lot of ground … both in general terms and with regard to the use of Aconex I’d like to leave you with a few thoughts *** TBC *** *** TBC *** *** TBC *** *** TBC *** *** TBC *** Thank you My name is Tim Crisp Systems & Co www.systemsandco.com
• #20: CONCLUSION: We’ve covered a lot of ground … both in general terms and with regard to the use of Aconex I’d like to leave you with a few thoughts *** TBC *** *** TBC *** *** TBC *** *** TBC *** *** TBC *** Thank you My name is Tim Crisp Systems & Co www.systemsandco.com
• #22: Aconex is the one single Could platform connecting all project participants project-wide, 24/7, from any device (including phones and tablets), anywhere in the world. It’s all about managing all of the information and processes for the world’s largest construction and engineering projects, with end to end support across the full project lifecycle. With workflows, routing, & the broadest suite of applications + processes, Aconex connects processes and data, providing a common data environment and an unalterable audit trail. Aconex allows you to adapt, scale, & execute processes quickly, with visibility of project history at every project phase.
• #23: To ensure that you have visibility and control across project processes that run between organizations, every company needs to trust using a collaborative, project-wide system. With Aconex, there are no barriers to collaborate. Every project member has access at no additional cost, and it’s easy to use. Each company has its own private workspace and owns its own data. No single company can change the audit trail, and there is no delete button. This results in accountability, process visibility beyond company walls, and less disputes. And with more people using the system, there are more accurate insights. Process visibility beyond company boundaries helps you pinpoint bottlenecks, drive accountability, and make better decisions. And the unalterable audit trail lets you avoid disputes and resolve them faster. You’ll have critical information at every project phase, including a “digital twin” of the entire project at handover.
• #24: Siloed systems and data lead to incomplete project information. Aconex supports critical processes across the entire project lifecycle. We offer an integrated suite of applications across design and construction, project controls, jobsite quality and safety, and handover. Aconex connects to other systems in your ecosystem so you can realise the benefits of connected data. You can automate data consolidation processes resulting in better insights and decision making. You have insights at your fingertips, keeping your projects on track and facilitating painless handover And with everything connected, you have one constant source of truth that is always up to date.
• #25: With Connected Processes & Data in the one common data environment you have access to insights at the process, project and portfolio level. At a process level you can identify bottlenecks and keep processes on track before it becomes too late. At a project level, you can measure performance and at a portfolio level you can predict performance and apply learnings to improve performance, establishing a process of continuous improvement.
• #26: It’s increasingly difficult to efficiently organise, process and group project documentation. Aconex Packages allow a project’s documentation and correspondence to be broken down into discreet controlled sections, or ‘packages.’ Packages better track and manage the many project processes through design, construction and completion of the project. Packages provide the means to better control the design and construction processes for a project. They ensure the right information is grouped and distributed for approval in design, and during construction control the capture of quality documentation prior to sign off. Packages structure project delivery to ensure a quality product is handed over to the client or asset owner. There are three key use cases for Packages: Design Management Design packages are created with metadata according to the requirements of the design scope / managements. These are then distributed to the collaborators, and added to as required, to develop the design documentation. The design package can be sent for review, via templates, and review progress can be tracked. Configuration Management: Detailed work processes, primarily for Heavy Engineering, e.g. EPCs. Managing change and controlling the technical and engineering ramifications of the design – the impact of the design. Gathering of project documentation is controlled by a strict submission and tracking methodology. Work Packaging: Also known as 'Lot Management' in ANZ. During construction this controls Lot / Work Package Management, managing processes that demonstrate completion of work. Quality teams manage verification. Closure of the package provides evidence of satisfactory completion and also tracks completion rate of the work against the construction schedule. Particularly applicable to self-perform contractors.