Blog

Eindelijk een instrument om Project Scope te beheren

Joao Mirandaby Joao Miranda | In Oracle Prime, Primaned Blog, Scope, Tools |

Lange tijd associeerde men projectmanagement met plannen. Natuurlijk waren de meeste projectgebaseerde softwaretools, zoals Microsoft Project of Primavera P3 en de daaropvolgende Primavera P6 Professional, gericht op dat proces. Er bestonden wel andere tools, die zich op verschillende gebieden richten, maar altijd zeer specifiek, zoals Primavera Risk Analysis bijvoorbeeld, dat zich richt op risico’s. Er bestond geen uitgebalanceerde en geïntegreerde tool. Deze blog is Engelstalig.

For a long time, when thinking about Project Management, the first thing people associate to was scheduling. Naturally, most project-based software tools, like Microsoft Project or Primavera P3 and the subsequent Primavera P6 Professional, were focusing on that process. Other tools existed, focusing on different areas, but always a specific one, like Primavera Risk Analysis, for example, which focuses on risks. No well-balanced and integrated tool did exist.

But the world is changing fast. At Primaned Belgium, we always believed that “the real power of project controls lies in the integrated approach to manage its areas”, and never our belief made more sense. Business requirements are ever more challenging, projects are ever more complex, forcing Project Controls field to increase its effort for a better integration between the different knowledge areas.

So, the toolbox must adapt, it must become broader. We have analyzed several tools, mapped them with our client’s business needs, and recently we have seen a set of new powerful tools emerging, among them Oracle Prime.

Oracle Prime

Primaned has already introduced Prime in a previous post. Now, we will dedicate a series of blog posts focusing the apps or modules.

In simple terms, Project Management is about balancing different constraints with the goal to deliver a product, a service or a result. Oracle Prime is essentially a comprehensive solution that deals with those constraints, namely scope, schedule, cost, etc., that is the different knowledge areas of project controls, each of them covered by its own independent module and integrates them into a single application.

The Scope app

When developing a project, the first thing that must be defined are the deliverables of that project, to wit, the scope. So, it seems natural we start with the Scope app.

As stated in the PMBoK, scope is “the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions”. In more simple terms, the product to be delivered and all the necessary work to deliver it.  The app within Oracle Prime clearly follows this idea by dividing Scope between Product and Work.

Product can be simply put as “what to deliver”. So, in Prime, we describe it by breaking down hierarchically the end-product into its components or sub-products, creating then, the PBS (Product Breakdown Structure) of our project, as the one below, as recommended by the Project Management best practices, which is also kind of unique within Project Management tools. In P6, for example, no similar functionality exists. We see some P6 users creating a PBS, by assigning activity codes, but that does not give us the same functionality as we have here, as will become clear later in this post.

Similarly, Work can be regarded as “what must be done” and we represent it by the so-called WBS (Work Breakdown Structure), as the one below, breaking down hierarchically all necessary effort to deliver the product, with the specified features, and achieve the project goals, into discrete phases, levels or layers, creating smaller deliverables or work packages.

In the end, after all decomposition, scope can be described in detail by all quantities from all necessary components and all the hours from all the necessary effort, coming from labor resources or equipment. To put in another way, we have an accurately detailed bill of quantities, which is provided by each of the work packages we define, as the one shown in the next figure.

As it happens with schedules in P6, baselines are established as benchmark against which scope performance is measured as a project evolves. After establishing a baseline, scope can only be changed with a formal change request workflow; emulating the typical change approval procedures, like the one advocated by the PMI.

Balancing the Scope app

As we can verify, the Scope app of Oracle Prime focus on the project deliverables and provides us then an install-based deliverables management solution.

The great feature of the app is that it highlights the physical delivery of projects and allows a quantifiable assessment of the project performance on real physical terms. With it, physical percent complete equals in fact scope percent complete, built on quantities or on predefined rules of credit-based milestones.

Also, this module provides a platform for a proper integration with both schedule and cost app. With it, users can plan and track the product installation, assemblage or construction and related costs, without requiring a detailed schedule. However, every single piece of scope may be linked with activities from the schedule, allowing scope to inherit activities dates and scope to drive progress of activities, with the input of scope percent complete. This will clearly fill a gap that we found in other tools like MS Project or Primavera P6. Until now, determining the activity physical percent complete was always cumbersome.

Scope-based costs, on the other side, can be dragged to the cost app, by giving a CBS (Cost Breakdown Structure) code to each of the items. This means scope quantities are used as input for cost estimation.

Also, a scope-loaded schedule and budget allows the creation of a time-phased budget.

As any tool, the Scope app also has some downsides and it is our philosophy to be transparent about them. We find it to be our role to give a balanced view to our customers, but also to raise enhancement requests to Oracle as industry experts. This is exactly what we have already done with the downsides explained next.

First, the definition of project scope can be somewhat confusing. For example, Work Packages are not really the lowest level of the WBS as defined by the project management field. In Prime, they are defined outside the WBS, underneath its last level. Also, how scope is defined can be regarded as complex, for some, with too many steps to take. Because of both reasons discussed above, the entire scope definition process is somewhat counterintuitive and more time-consuming than it could have been. This is surprising as Oracle Prime is in general praised for its intuitiveness and ease of use. As an example, scope assignments need to be handled inside each of the work packages, so we need to go inside each of those, one by one, to manage the assignments. There is no general view where we could do that together, preferably with fill down functionality.

Last, some integration is still missing, like for example between the Scope and the Resources app. Many scope elements can be described as a resource, so integration would be a nice add-on.

Conclusion

Altogether though, we are truly enthusiastic about the Scope app and we believe it is truly a wonderful solution to plan, manage and control the physical evolution of a project. Quite often our clients ask for schedule management, while their real problem lies with the scope. Finally, we have a tool that will provide a solution to address that problem and integrate both. And the downsides? Not only are they outweighed by the advantages, but we are also confident that Oracle will tackle them in one of the upcoming releases.

Primaned is already implementing this tool and we are certain that many other implementations will follow, because it provides easy and clear insights to clients which main concern is to ensure the delivery of the product, service or result with all the required features and functionality.

Trackback from your site.

Leave a comment