Saturday Sep 26, 2015

MoSCoW Grooming

I was recently asked whether the MoSCoW List (list of known business requirements classified by the first letter of: Must, Should, Could or Won’t) is a static document. The short answer to this is No – the MoSCoW List is intended to be evolved, some use the term “groomed”, as the project progresses. MoSCoW grooming is a good process to indicate what is inside or outside scope for the project as a whole, as well as for a given phase and/or iteration.

The MoSCoW List is initially created in the Inception phase, but this does not mean that you do not continue prioritizing further into the project. In fact, you groom the MoSCoW list using prioritization techniques throughout the project. You indicate priorities for each use case defined. However, all the detailed requirements should be related to the requirements given in the MoSCoW List.

When the project moves into the Elaboration phase, you also use these priorities to determine on which use cases to start. The Should Haves are not as important as the Must Haves and may not even be considered during the Elaboration phase.

This classification makes our understanding explicit as soon as project progress changes. New functionality can appear and be prioritized as necessary while other initial requirements turn out to be less important.

The ultimate MoSCoW List should be a mutually exclusive and completely exhaustive set of functional and supplemental requirements. Each requirement should relate to at least one of the objectives stated in the Business and System Objectives (RD.001).  

Do you have any tips for MoSCoW grooming?  Please share them in the comments.

Tuesday Mar 31, 2015

OUM Spotlight - Keeping Stakeholders Engaged

Congratulations! Your new project is off to a great start and all of the stakeholders came away from the project kickoff meeting informed and enthused. Now you may be wondering how do I keep these very busy stakeholders informed and enthused as the project moves along?  One technique used by successful OUM projects is to communicate the project's status to all of the stakeholders upon the completion of the phase end milestones, and take this milestone opportunity to inform these stakeholders of upcoming critical events and decisions. This practice connects stakeholders into the flow of the project, thus promoting collaborative working relationships and reducing risk by continually demonstrating project progress and driving decision making.

Another widely used technique is to demonstrate configurations and extensions to ambassador users at key points in the development cycle. This gives ambassador users the ability to conduct testing throughout the project, which facilitates a smooth UAT and mitigates any potential surprises at the end of the project.

Have any tips and techniques on keeping stakeholders engaged on your projects?  Please share in the comments.

Saturday Oct 11, 2014

Questions to Ask When Organizing Your OUM Workplan

So you’ve read all the tips and blogs about how to tailor OUM for your project and you’ve figured out what tasks you need. Now you have to put them into a workplan. What do you do? Do you use the traditional activity wbs structure highlighted in the method or do you need something else? The possibilities are endless. Think about how you implement your projects now. Think about what works now and what doesn’t. Consider this blog my Questions to Ask When Organizing Your OUM Workplan.

  1. Does the traditional OUM activity-work-breakdown structure fit my project?
  2. Does your project involve more than one custom-off-the-shelf (COTS) product? If so, maybe you want to do this work in partitions. Determine which activities/tasks should be duplicated into each partition.
  3. Do you need to consider copying sections of your workplan and putting them into iterations for accommodating use case packages?
  4. Can certain processes be run as “mini projects?” Some processes can almost be run as a side project on their own, for example, Technical Architecture (TA), Performance Management (PT), Documentation (DO), Training (TR), and Organizational Change Management (OCM). If so, it may make more sense to group and track these tasks under a process/activity heading and not space them out into the various phases.
  5. Do you use one workplan or a master workplan with individual plans that report or roll up into the master? This might work if you have Team Leaders that manage specific pieces of work. Use a placeholder activity/task in the master workplan and the detail can be managed in a sub workplan.

The bottom line is, be creative. Build your workplan(s) to suit your project. As you start another project, don’t be afraid to change something that isn’t working. Finally, share your workplans and experiences.

Wednesday Sep 24, 2014

Checklists Are Leading Edge

I recently ran across this blog on The Power of Checklists by Ivar Jacobson. In it he describes the value of using checklists on software projects since they: “keep software projects on track, and help maximize the delivery of value, and minimize the risk of project failure.” OUM practitioners know this since the method contains checklists in many places - templates, phase overviews, activities, tasks, etc.  In fact, the WBS itself could be considered a checklist since the activities and tasks are merely “placeholders for work.”

The OUM checklists which I find particularly valuable are the Activity Checklists found in each of the Lifecycle Milestone Summaries. These checklists are designed to assist you with the determining “completeness” of the project at that point. They also contain lists of key decisions and common risks that should be addressed during that particular phase of the project – kind of like a “you are here” checkpoint for the project's progress.

I think Ivar would agree with me about the value of the OUM Activity Checklists since he is a fan of Barry Boehm’s standard project milestones. You can read more about Barry Boehm’s standard project milestones in his seminal work – “Anchoring the Software Process” [Barry Boehm, November 1995].

Which OUM checklists do you find to be of the most value? Please share your opinion in the comments.

Wednesday Aug 06, 2014

Guard Against the Multitasking Brain Drain with OUM

Most people are aware of the perils of multitasking – it is bad for productivity, increases the possibility of distractions, and basically creates a mental traffic jam. It not only wreaks havoc in everyday life but also causes major problems on projects. If you look at OUM you might be thinking, “Hey wait! Isn’t the fact that OUM’s processes run in parallel and that it takes a cross-functional approach really multitasking?” My response to you (to borrow from Lee Corso) is, “Not So Fast, My Friend!”

The answer is directly related to magnitude of the shifts in focus. We know that those broad deviations in requirements and technology require more adjustment and time to switch gears. Human brains are okay with shifting tasks within reasonable limits. On a well managed OUM project, the team is focused on a discrete, prioritized list of functionality and technology. Only a limited number of logically grouped requirements are being worked at a time in order to achieve specific milestones. This means there is a narrow span of scope being addressed at any point in the project, even there may be a wide range of tasks and processes in play.

Extensive detours such as new requirements and major shifts in priorities are the catalysts that can lose the project to the nemesis known as multitasking. Fortunately, OUM has a number of tools to keep the focus and guard against the multitasking brain drain – timeboxes, MoSCoW lists, use cases, and system context diagrams...just to name a few.

What are some tools you use to keep your projects focused? Please share with us in the comments section below!

Thursday May 29, 2014

Success Quote: A Hybrid Approach for Success

We recently received this quote from a project that successfully used OUM: “On our project, we applied a combination of the Oracle Unified Method (OUM) and the client's methodology. The project was organized by OUM's phases and a subset of OUM's processes, tasks, and templates. Using a hybrid of the two methods resulted in an implementation approach that was optimized for the client-specific requirements for this project."

This hybrid approach is an excellent example of using OUM in the flexible and scalable manner in which it was intended. The project team was able to scale OUM to be fit-for-purpose for their given situation. It's great to see how merging what was needed out of OUM with the client’s methodology resulted in an implementation approach that more closely aligned to the business needs.

Successfully scaling OUM is dependent on the needs of the particular project and/or engagement. The key is to use no more than is necessary to satisfy the requirements of the implementation and appropriately address risks. For more information, check out the "Tailoring OUM for Your Project" page, which can be accessed by first clicking on the "OUM should be scaled to fit your implementation" link on the OUM homepage and then drilling into the link on the subsequent page.

Have you used OUM in conjunction with a partner or customer methodology? Please share your experiences with us.

Tuesday Mar 25, 2014

New in OUM - The Abbreviated PMP Template

Did you know that OUM now contains an Abbreviated Project Management Plan (PMP) template in the BT.070 – Create Project Management Framework task?  If you have been around OUM for a while, or have been a project manager using another methodology that aligns to PMI's global standards, you know that the PMP is key to promoting project success. The PMP is the work product that captures the project approaches for all of the OUM Manage processes. The Abbreviated PMP template in OUM is a MS-PowerPoint deck that serves to encapsulate the essential elements of the overall plan into a single presentation.

The Abbreviate PMP is applicable for smaller (<500 day projects is the general recommendation) and/or agile projects which call for lightweight, low-ceremony documentation. It is also well-suited to the PMP index approach where planning documents are written as separate documents and then linked within the master presentation. In any kind of project, it can serve as a scalable presentation which may be used during the project kick-off or other team meetings.

Regardless of which approach you take on your project, the PMP template (or any OUM work product for that matter) should be revised to fit the needs of your project.

Check out the new Abbreviate PMP template and let us know your thoughts.

Monday May 06, 2013

The Eating Contest - How a software project is like an eating contest

It may be hard to imagine, but there are some similarities between software projects and eating contests. No, I'm not implying that both are messy  and leave you feeling ill. Done properly, only an eating contest will produce those results.

What I am talking about is that both eating contests and software projects should employ an iterative and incremental approach. In other words, smaller chunks are better whether you're eating or implementing.

Click here to hear about a guy named Steve, his eating contest exploits, and how my sleeping brain made a connection between Steve's approach and successful software projects. This brief video describes OUM's principle of iterative and incremental and how it should be used to create success in eating contests and on software projects.

Whether it's an on-premises implementation or enabling a customer in a public cloud environment, businesses expect very rapid time to value for all of their IT investments. An iterative and incremental approach helps implementers live up to those expectations.

Once you're finished viewing the video please leave a comment or go to the "Oracle Unified Method" group on LinkedIn to give us your thoughts.

Monday Apr 22, 2013

Tailoring the OUM Workplan

Did you know that OUM has guidance for tailoring your project?

Located in the Supplemental Guidance section of the Key Components on the Manage view is the Tailoring OUM for Your Project guidance.  This guidance describes a step-by-step process for tailoring OUM for your project.  This process starts with the Estimate and/or Proposal and ends with Assigning Resources and Duration to Activities and Tasks. 

What this blog focuses on is the tailoring of the actual OUM Project Workplan for your project for activities and tasks (tailoring steps 2.0 through 5.2) including tips for applying a bottom-up as well as a top-down technique for tailoring the Project Workplan.  So let’s get started.

For our example, we are starting with the OUM Project Workplan that is located in the Method Resources section of the Key Components of most view pages. In OUM 5.6, a new Project Workplan template was introduced with pre-tailoring capability for most Implement views.  Our example project also is most closely aligned with the Requirements-Driven Application Implementation view.

To develop our Project Workplan, we have several options.  We can employ a top-down approach and start with all of OUM and tailor it down.  We can employ a bottom-up approach and start with the Core Workflow and build up from there.  The best approach is probably to start with the workplan that most closely matches our engagement and tailor up and down.  That is, immediately tailor down to a pre-tailored Workplan and continue to tailor from there based on the requirements of the engagement, while simultaneously keeping in mind the Core Workflow and building up from there.

So for our example, we are starting with the Requirements-Driven Application Implementation pre-tailored OUM Project Workplan.

Our next step is to eliminate activities/tasks that are not needed. Consider the following:
  1. Don’t eliminate anything in the Core Workflow without carefully consideration.
  2. Review any available supplemental guidance.
  3. Consider removing activities/tasks NOT included in the Estimate and/or Proposal.
  4. Determine if it’s possible to eliminate all if not most of some processes. For example, consider removing the following processes and corresponding activities and/or tasks, if your project does not include ANY requirements for them:
  • Performance Management
  • Organizational Change Management
  • Training
  • Data Acquisition and Conversion
Now that we have tailored down, we should consider if we need to add any activities/tasks.  These include two types of activities/tasks:
  • Activities/Tasks that were excluded from the Requirements-Driven Application Implementation pre-tailored Project Workplan, and
  • Project-Specific (Custom) Activities/Tasks

For the excluded activities/tasks, use the 01_OUM_Set_Project_Filter view of the OUM Project Workplan to review any activities/tasks that were not included in the Requirements-Driven Application Implementation pre-tailored OUM Project Workplan and determine if they are needed for the engagement.

Project-specific custom activities/tasks are activities/tasks that are not already included in OUM. Add these to the Project Workplan.

Now we have a tailored OUM Project Workplan for our engagement.  However, we still need to apply partitioning, if applicable, and iteration planning.  This however is a topic for another blog.  In the meantime, I encourage you to peruse the following OUM guidance:

From the Manage view, Key Components, Supplemental Guidance:

  • Planning a Project using OUM
  • Tailoring OUM for Your Project

Form the Manage view, Key Components, Method Resources

  • OUM Project Workplan – This link accesses the Project Workplan page which allows you to download a zipped file containing the Project Workplan and the Project Workplan User’s Guide.

Finally, you might also want to review the Task Overviews for WM.010 (Develop Baseline Project Workplan) and WM.030 (Manage Project Workplan).

Thursday Jan 10, 2013

OUM Manage - The Key to Marital Bliss

During a recent blog on “Applying the Iterative and Incremental Principle”, a follower commented that the waterfall approach was responsible for the demise of his marriage.  He mused that his marriage may have had a chance if he had followed an iterative and incremental approach!

Although this exchange was meant to be amusing, it prompted me to think about the similarity between a conventional marriage and the “marriage” that occurs when an OUM project is initiated.   Without getting into a political debate on the definition of marriage, for the purpose of this blog, let’s consider an OUM Implementation a type of marriage entered into by the Project Manager and the Project Sponsor for the term specified in the contract or Statement of Work (SOW). 

What makes a one marriage successful while another fails?  If you ask five people this question, you would likely receive five different answers based on their unique experience, but I speculate the answers would fall into similar themes:

  • Communication
  • Trust
  • Ability to manage expectations

In OUM Manage, one of the first activities that occur during the Project Startup phase involves the Project Manager and the client (Project Sponsor) jointly creating the Project Management Framework.  This framework establishes the ground rules for the project and is the first step in communicating, establishing trust, and setting expectations.

The key focus for the remainder of the Project Startup Phase is to evolve the Project Management Framework into a detailed Project Management Plan based on the agreed upon foundation.   In prior versions of OUM Manage, the equivalent work product was named the “Terms of Reference”.  Literally, this was the work product referenced to sort out problems when future misunderstandings occurred.   

The PMP establishes, early on, what needs to be done, who should do it, and how it will get done.  Issues and problems are anticipated and resolution approaches are agreed to in advance.  Once the PMP details the who, what, and how, the plan is monitored and updated as the relationship matures and the parties have a better understanding of what works and does not work in their relationship. 

Specifically, the PMP addresses Work Management, Financial Management, Communications Plan, Risk Management, Issue Management, Problem Management, Staff Management, Procurement Management, Infrastructure Management, Quality Management, Organizational Change Management Strategy and more!  I am not a marriage therapist, but I can clearly see the advantage to sitting down and agreeing to these areas early on, and of refining as the relationship grows.   Clearly, the Project Management Plan or PMP is a critical success factor for marital bliss! 

If you think about the positive affect that creating a PMP equivalent would have on a conventional marriage, you should appreciate the value of creating a PMP for every project to increase its chance of success.  Think about the potential issues (risks) that can be mitigated by having a candid discussion on the approach to finances (need I say more?), work responsibilities (who cooks? Who cleans?), staffing (housekeeper or no housekeeper?), Risks (in-laws next door), and Organizational Change Management (kids!) and so on.  If these areas are not discussed until there is a conflict, without a clear approach to how to deal with the potential conflict, the likelihood that trust will erode and the relationship deteriorate increases.

For anyone contemplating marriage – whether conventional or in the project sense, I strongly advice that you emulate OUM Manage and create an equivalent to the Project Management Framework when you are engaged, and that you detail this framework during your engagement -- prior to the nuptials!  If this is done, then you should have much more confidence in the success of the union!

Wednesday Dec 05, 2012

The Workshop Technique Handbook

The #OUM method pack contains a plethora of information, but if you browse through the activities and tasks contained in OUM, you will see very few references to workshops.  Consequently, I am often asked whether OUM supports a workshop-type approach. 

In general, OUM does not prescribe the manner in which tasks should be conducted, as many factors such as culture, availability of resources, potential travel cost of attendees, can influence whether a workshop is appropriate in a given situation.  Although workshops are not typically called out in OUM, OUM encourages the project manager to group the OUM tasks in a way that makes sense for the project.

OUM considers a workshop to be a technique that can be applied to any OUM task or group of tasks.  If a workshop is conducted, it is important to identify the OUM tasks that are executed during the workshop.  For example, a “Requirements Gathering Workshop” is quite likely to Gathering Business Requirements, Gathering Solution Requirements and perhaps Specifying Key Structure Definitions.

Not only is a workshop approach to conducting the OUM tasks perfectly acceptable, OUM provides in-depth guidance on how to maximize the value of your workshops.  I strongly encourage you to read the “Workshop Techniques Handbook” included in the OUM Manage Focus Area under Method Resources.

The Workshop Techniques Handbook provides valuable information on a variety of workshop approaches and discusses the circumstances in which each type of workshop is most affective.  Furthermore, it provides detailed information on how to structure a workshops and tips on facilitating the workshop. You will find guidance on some popular workshop techniques such as brainstorming, setting objectives, prioritizing and other more specialized techniques such as Value Chain Analysis, SWOT analysis, the Delphi Technique and much more.

Workshops can and should be applied to any type of OUM project, whether that project falls within the Envision, Manage or Implementation focus areas.  If you typically employ workshops to gather information, walk through a business process, develop a roadmap or validate your understanding with the client, by all means continue utilizing them to conduct the OUM tasks during your project, but first take the time to review the Workshop Techniques Handbook to refresh your knowledge and hone your skills. 

Friday Oct 12, 2012

Iterative Project Planning - Let's Talk

I recently had an interesting conversation with a Project Manager regarding the shift from a "Waterfall" approach, to an Iterative approach to managing projects. Click on the following link to see an animated version of that conversation!


Friday Sep 28, 2012

Iterative and Incremental Principle Series 5: Conclusion

Thank you for joining me in the final segment in the Iterative and Incremental series.  During yesterday’s segment, I discussed Iteration Planning, and specifically how I planned my daily exercise (iteration) each morning by assessing multiple factors, while following my overall Implementation plan.

As I mentioned in yesterday’s blog, regardless of the type of exercise or how many increment sets I decide to complete each day, I apply the 6 minute interval sets and a timebox approach.  When the 6 minutes are up, I stop the interval, even if I have more to give, saving the extra energy to apply to my next interval set.  

Timeboxes are used to manage iterations.  Once the pre-determined iteration duration is reached – whether it is 2 weeks or 6 weeks or somewhere in between-- the iteration is complete.  Iteration group items (requirements) not fully addressed, in relation to the iteration goal, are addressed in the next iteration.  This approach helps eliminate the “rolling deadline” and better allows the project manager to assess the project progress earlier and more frequently than in traditional approaches.

Not only do smaller, more frequent milestones allow project managers to better assess potential schedule risks and slips, but process improvement is encouraged.  Even in my simple example, I learned, after a few interval sets, not to sprint uphill!  Now I plan my route more efficiently to ensure that I sprint on a level surface to reduce of the risk of not completing my increment. 

Project managers have often told me that they used an iterative and incremental approach long before OUM.   An effective project manager naturally organizes project work consistent with this principle, but a key benefit of OUM is that it formalizes this approach so it happens by design rather than by chance.   

I hope this series has encouraged you to think about additional ways you can incorporate the iterative and incremental principle into your daily and project life.  I further hope that you will share your thoughts and experiences with the rest of us.

Thursday Sep 27, 2012

Iterative and Incremental Principle Series 4: Iteration Planning – (a.k.a What should I do today?)

Welcome back to the fourth of a five part series on applying the Iteration and Incremental principle.  During the last segment, we discussed how the Implementation Plan includes the number of the iterations for a project, but not the specifics about what will occur during each iteration.  Today, we will explore Iteration Planning and discuss how and when to plan your iterations.

As mentioned yesterday, OUM prescribes initially planning your project approach at a high level by creating an Implementation Plan.  As the project moves through the lifecycle, the plan is progressively refined.  Specifically, the details of each iteration is planned prior to the iteration start.

The Iteration Plan starts by identifying the iteration goal.  An example of an iteration goal during the OUM Elaboration Phase may be to complete the RD.140.2 Create Requirements Specification for a specific set of requirements.  Another project may determine that their iteration goal is to focus on a smaller set of requirements, but to complete both the RD.140.2 Create Requirements Specification and the AN.100.1 Prepare Analysis Specification. 

In an OUM project, the Iteration Plan needs to identify both the iteration goal – how far along the implementation lifecycle you plan to be, and the scope of work for the iteration.  Since each iteration typically ranges from 2 weeks to 6 weeks, it is important to identify a scope of work that is achievable, yet challenging, given the iteration goal and timeframe. 

OUM provides specific guidelines and techniques to help prioritize the scope of work based on criteria such as risk, complexity, customer priority and dependency.  In OUM, this prioritization helps focus early iterations on the high risk, architecturally significant items helping to mitigate overall project risk. 

Central to the prioritization is the MoSCoW (Must Have, Should Have, Could Have, and Won’t Have) list.   The result of the MoSCoW prioritization is an Iteration Group.  This is a scope of work to be worked on as a group during one or more iterations. 

As I mentioned during yesterday’s blog, it is pointless to plan my daily exercise in advance since several factors, including the weather, influence what exercise I perform each day.  Therefore, every morning I perform Iteration Planning.   My “Iteration Plan” includes the type of exercise for the day (run, bike, elliptical), whether I will exercise outside or at the gym, and how many interval sets I plan to complete.   

I use several factors to prioritize the type of exercise that I perform each day.  Since running outside is my highest priority, I try to complete it early in the week to minimize the risk of not meeting my overall goal of doing it twice each week.  Regardless of the specific exercise I select, I follow the guidelines in my Implementation Plan by applying the 6-minute interval sets.  Just as in OUM, the iteration goal should be in context of the overall Implementation Plan, and the iteration goal should move the project closer to achieving the phase milestone goals.

Having an Implementation Plan details the strategy of what I plan to do and keeps me on track, while the Iteration Plan affords me the flexibility to juggle what I do each day based on external influences thus maximizing my overall success.

Tomorrow I’ll conclude the series on applying the Iterative and Incremental approach by discussing how to manage the iteration duration and highlighting some benefits of applying this principle.

Wednesday Sep 26, 2012

Iterative and Incremental Principle Series 3: The Implementation Plan (a.k.a The Fitness Plan)

Welcome back to the Iterative and Incremental Blog series.  Yesterday, I demonstrated how shorter interval sets allowed me to focus on my fitness goals and achieve success.  Likewise, in a project setting, shorter milestones allow the project team to maintain focus and experience a sense of accomplishment throughout the project lifecycle.  Today, I will discuss project planning and how to effectively plan your iterations.

Admittedly, there is more to applying the iterative and incremental principle than breaking long durations into multiple, shorter ones.  In order to effectively apply the iterative and incremental approach, one should start by creating an implementation plan.  

In a project setting, the Implementation Plan is a high level plan that focuses on milestones, objectives, and the number of iterations.  It is the plan that is typically developed at the start of an engagement identifying the project phases and milestones. 

When the iterative and incremental principle is applied, the Implementation Plan also identified the number of iterations planned for each phase.  The implementation plan does not include the detailed plan for the iterations, as this detail is determined prior to each iteration start during Iteration Planning.  An individual iteration plan is created for each project iteration.

For my fitness regime, I also created an “Implementation Plan” for my weekly exercise.   My high level plan included exercising 6 days a week, and since I cross train, trying not to repeat the same exercise two days in a row.  Because running on the hills outside is the most difficult and consequently, the most effective exercise, my implementation plan includes running outside at least 2 times a week.   Regardless of the exercise selected, I always apply a series of 6-minute interval sets.

 I never plan what I will do each day in advance because there are too many changing factors that need to be considered before that level of detail is determined.  If my Implementation Plan included details on the exercise I was to perform each day of the week, it is quite certain that I would be unable to follow my plan to that level.  It is unrealistic to plan each day of the week without considering the unique circumstances at that time.  For example, what is the weather?  Are there are conflicting schedule commitments?  Are there injuries that need to be considered?  Likewise, in a project setting, it is best to plan for the iteration details prior to its start.

Join me for tomorrow’s blog where I will discuss when and how to plan the details of your iterations.


OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.


· Brief

· White Paper

· Customer Program Data Sheet


· OUM on Twitter

· OUM on LinkedIn


« July 2016