Wednesday Mar 19, 2014

Scrum Teams -- Do you feel the rhythm?

Hi, I’m Terri Merenkov a member of the Global Methods team at Oracle. This month I celebrate my 18th year with Oracle. You might be surprised by that, but many in the Global Methods team have more tenure than I do. This is part of what makes my job so interesting. If I don’t know the answer to something about Oracle Implementation projects of a certain type, I don’t have to go far to find someone who does. Even though some concepts have been around for a while, there is always something new coming so we are constantly adapting and changing.

We have many things to learn about, today, even though they may have been around for a while, for example Scrum. Scrum was created in 1993 by Jeff Sutherland. The term “scrum” is borrowed from an analogy used in the 1986 study by Takeuchi and Nonaka (Takeuchi), published in the Harvard Business Review. In the study, the authors equated high-performance, cross-functional teams to the packs formed by Rugby teams.

Here we are nearly two decades later actually applying Scrum in our software development projects. Yet some people think that Scrum is new,maybe it is coming into the mainstream perhaps because we realize that often taking something large and breaking it down helps support a successful software implementation.  It is only now that we're seeing teams celebrate success using Scrum.  Of course, not everyone is successful. Scrum seems so simple, it's often the human factor that really determines how well things go.

In the 80’s I was very into music, I started in University as a music education major. My major was percussion as well as piano, with a minor in French. At the time, I had no idea what a computer was, however, I was playing electric keyboards “synthesizers” with built-in percussion instruments of course I was enamored with the Mellotron and Moog synthesizers that were being used by some of the progressive rock bands. Once I discovered that music was being cut from the curriculum of many schools, I decided to re-think my major. A software “recruiter” lived across the street from me. She suggested that I try taking some computer courses, since often people who are good at music and language happen to excel in using computers. I began taking classes in computer science, and the more I learned, the more I wanted to know!

I find it interesting at this point in my life, I’m being reminded of good things that I learned about when I was younger, that are actually useful in my adult life – today.

Just the other day, I was working on some updates to the Scrum View in OUM and I came across the word “Cadence”. Oh, I thought, I know about Cadence! Any good drummer knows that a cadence is needed to get the marching band to stay in step when marching across the football field or in a parade.  Of course the percussionists are experts in various percussion instruments,

The percussionists in a marching band have a natural rhythm, in fact when the band is marching in between songs, the percussionists are keeping a cadence that allows everyone to step together, as part of a group, each individual takes nice even steps until we’re in place to play the next song.  This rhythm can me a steady tapping on the drum "rims" or use of the full percussion instrument.

So think about a Scrum team, just the way you would think about a group of musicians in a band. Good Scrum teams “feel the rhythm” they have a cadence that allows the team to work together easily, almost naturally. With each Sprint retrospective, they examine what worked and what didn’t. Over the course of several Sprints, a true cadence is achieved by the team. A sustainable team cadence leads us to another term used in the Scrum approach; velocity.

When I think of velocity, I think of speed, but in a software development effort, speed isn’t always our main focus. In Scrum, velocity is obtained by calculating the number of units of work that can be completed by the team during a specific timeframe (Sprint). Velocity refers to the speed at which a team can implement and test use cases (user stories) and change requests (that is, how much of the product backlog the team can complete). This is reflected in the Burndown Charts by showing the progress made so far versus the planned/estimated progress. Of course with each Scrum Sprint, the team becomes more experienced, and can determine velocity based on how many units of work they have completed during previous Sprints.

 

Contrary to what some may say, even though Scrum uses the word Sprint, we aren’t necessarily only focused on going as fast as we can until we burn out the team. Rather, we work on building teams that can develop, test and integrate working software in a collaborative, yet agile fashion.  This results in a sustained rhythm. So I ask you - can YOU feel the rhythm? What experiences have you had in building expert teams that work well together?  Have you used Scrum successfully and why?  Listen... do you feel it?

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).

Wednesday Jan 30, 2013

A Method Store – Supplemental Guidance (Understanding the Structure of OUM)

My last blog in this series on understanding the structure of OUM discusses supplemental guidance.  This is the final section of the OUM Repository “store” that you need to consider.

Going back to our grocery store comparison, the grocery store contains additional specialty items.  These items complement the groceries.  You don’t always need these items, but sometimes they come in handy.  These items might include sections for gourmet or hard to find groceries, a book section with cookbooks or a section with small kitchen appliances and utensils.  While you don’t need these items all the time, different items may be useful for different recipes or occasions.

OUM has supplemental guidance that complements the base method materials.  This is additional supplemental inventory that might be useful for your project.  Just as you narrowed down the base method materials based on your type of project, you can also narrow down the supplemental guidance based on your type of project.

If you have decided to use a particular view, applicable supplemental guidance can be found in the Key Components section at the top of the view.  The first column contains view-specific supplemental guidance.  For example, if your project is a Requirements-Driven Application Implementation, this view includes links to the Application Implementation Overview and Supplemental Guide.  

Additional supplemental guidance is found in the second column of the Key Components.  This can be anything from additional supplemental guides, such as Oracle Support Services, to additional resource links.  The last link in this column is to the OUM Supplemental Guidance page that provides an Index to ALL supplemental guidance in OUM

The final column in the Key Components section of the view is to method resources.  This includes the OUM Project Workplan, Key Work Products and the OUM mappings.

Review the resources found in the Key Components section of your selected view or go straight to the Supplemental Guidance page from the Method Navigation pull-down menu of any view in OUM and see what additional guidance is available in OUM and if it is useful for your current project.

Monday Jan 28, 2013

A Method Store – Views (Understanding the Structure of OUM)

This is the fourth blog in a series of blogs on the structure of OUM.  In the previous blogs, I compared the OUM repository to a grocery store or a store with method materials with three main departments (focus areas); Manage, Envision and Implement and each of these having sections for phases, processes, activities and tasks.

So now you have your project and you know you don’t need to use everything in OUM but with all this material, where do you start?

Start with a view, or a pre-populated shopping list that provides access to the method materials (or inventory) for a particular type of project, for example, Application Implementation, Software Upgrade, etc.  The OUM views have been determined with the help of experienced subject matter experts (SMEs).

Views can be selected from the OUM Home page using the Select a View pull-down menu.  Alternatively, you can use the Resources button on the Home page to go to the Resources page and from there open the View Catalog.  The View Catalog describes each of the views supported in the current release of OUM.

Each view is organized similarly to the original focus area views.  If applicable, there will be Guidelines sections for each focus area that allow you to access the phases and processes.  At the bottom will be a filtered list of Tasks and Work Products.

Start with the view that most closely matches your project and then tailor it for your project requirements.  You can even start with the OUM Implement Core Workflow and add additional method components based on your project requirements.

My next and last blog in this series will discuss OUM Supplemental Guidance.

Friday Jan 25, 2013

A Method Store – Base Materials (Understanding the Structure of OUM)

Once again, building on my previous blogs where I compared the OUM repository to a grocery store or basically a store with method materials with three main sections (focus areas); Manage, Envision and Implement.

Each focus area is organized similarly.  Within each focus area of the OUM repository, there are sections (or departments) for phases, processes, activities and tasks.

Phase guidance is found in the Phase Overviews.  Phases are a chronological grouping of tasks.  In OUM, services are delivered by phase in order to reduce project risk.  Each phase allows a checkpoint against project goals, and measurement against quality criteria.  Phases are temporal groupings, that is, they are bound by time.  They cut vertically through project activities and provide natural points for establishing project milestones for progress checkpoints.

Process guidance is found in the Process Overviews.  A process is a discipline or subproject that defines a set of tasks related by subject matter, required skills and common dependencies.  A process usually spans several phases.

Activity guidance is found in the Activity Overviews.  An Activity is a set of tasks related either by topic, dependencies, data, common skills/roles, or work products. The tasks in an activity may come from different processes.  Activities in OUM begin and end in the same method phase.  Activities are spread within the project phases according to the time and ordering where they logically occur during the life of the project.

Task guidance is found in the Task Overviews.  A task is a unit of work that is done as part of a project and results in a new or revised work product.  A task is the smallest traceable item on a project workplan, and forms the basis for a work breakdown structure.  A work product is simply the output of a task.  Many OUM tasks have work product templates.

Once again go to the Select a View menu on the OUM Home page and select “Full Method and Focus Areas”.  From this page, choose the focus view.  Once in any of the focus area view pages, expand the Guidelines window or choose it from the Current Page Navigation menu.  From within this window, you can access the focus area phases and processes.  You can access the tasks and their associated work products by expanding the appropriate Tasks and Work Products sections at the bottom of each focus area view.

Okay now that you know how the base method materials are organized in the OUM repository, my next blog will discuss the OUM views, or your pre-populated shopping lists.

Friday Jan 18, 2013

A Method Store - Focus Areas (Understanding the Structure of OUM)

If you remember my previous blog entry, I compared the OUM repository to a grocery store, that is, a store with method materials.  Just as the grocery store is organized into sections or departments, the OUM repository is segmented into three main sections or focus areas; Manage, Envision and Implement.  

Each of these focus areas has its own view.  From the OUM Home page, use the Select a View menu to go to the Full Method and Focus Areas page.  From there choose the focus area view.

The focus areas provide the framework for all the other method materials. Specifically, the Manage focus area provides the framework for program and project management.  The Envision focus area provides the framework for enterprise-level planning and the Implement focus area provides the framework for project implementation.  In OUM, focus area guidance is found in the Focus Area Overviews.

So, if you are making your shopping list for your project, ask yourself the following questions:
  • Do I need project management for my project?  In most cases, you always need project management and therefore, should consider the Manage focus area.
  • Is my project an enterprise-level planning project?  If so, consider the Envision focus area.
  • Am I implementing a COTS product, or doing a BI/EPM, WebCenter or custom project?  If so, consider the Implement focus area.
Once you know what focus area(s) you need, use the Select a View menu on the OUM Home page and select “Full Method and Focus Areas”.  From this page, choose the focus view.  Once in the view page, you can access the method materials available within each focus area, which is the topic for my next blog.

Thursday Jan 17, 2013

A Method Store (Understanding the Structure of OUM) - Introduction

This blog entry is the first in a series of blog entries to assist you in understanding the structure of the Oracle Unified Method.

The Oracle Unified Method (OUM) is a repository of information that can be used to support the entire enterprise IT lifecycle, including support for the successful implementation of every Oracle product.

Think of OUM as a grocery store filled with inventory (method materials) that can be used to implement your project.  When you shop, you never select everything in the grocery store.  You pick and choose what inventory is appropriate based on your grocery needs.  The same is true for the OUM repository.  You pick and choose the method materials appropriate for your project

When you shop at the grocery store, you have some idea of the inventory and how it is organized.  Even if you have never been in a grocery store, you know that the inventory is organized by sections or departments, such as, a bakery, and departments for meat, produce, dairy, canned goods, etc.  

The OUM repository or “store” contains a comprehensive set of method materials to support your projects.  These materials are organized as well.  The OUM inventory is organized by focus areas, phases, processes, activities, tasks, and work products.

Last, when you shop at the grocery store, you usually have a shopping list of what you need.  This list is based on experience, habit and planning.  

OUM has views, or pre-populated shopping lists that provide access to the method materials (or inventory) for particular types of projects, for example, Application Implementations, Software Upgrades, etc.

Now that we have been briefly introduced to the OUM repository and what it contains, my next few blogs will discuss how the OUM repository or “store” is organized.

Tuesday Jan 08, 2013

What's New in OUM 5.6: Updated Manage Homepage

Have you seen the updated Manage Focus Area homepage in the latest release of OUM?  If you have downloaded the recently released OUM 5.6, you may have noticed the Manage homepage was redesigned so that the primary navigation is now by activity, rather than by process as in prior releases. This was done based on feedback from our global PM community that they prefer to view and manage their projects at the activity level. The new activity diagram navigation allows a PM to see the major blocks of work that must be accomplished by phase. This enhancement provides a flexible checklist and high-level perspective preferred by many OUM project management practitioners.

If you still want to navigate through Manage via the process view (aka the Whale Diagram), you still can. Go to the bottom of the ‘Select a View’ list from the OUM homepage and select ‘Full Method and Focus Areas’. On this page, you can then select the both the primary Manage view or the Manage Process view.

Haven’t downloaded OUM 5.6 yet? Check out the official announcement for more information about how you can download the method pack and start taking advantage of the updates in OUM 5.6. In the meantime, your comments and feedback are very welcome.

Saturday Nov 03, 2012

The Birth of a Method - Where did OUM come from?

It seemed fitting to start this blog entry with the OUM vision statement.

The vision for the Oracle® Unified Method (OUM) is to support the entire Enterprise IT lifecycle, including support for the successful implementation of every Oracle product. 

Well, it’s that time of year again; we just finished testing and packaging OUM 5.6.  It will be released for general availability to qualifying customers and partners this month.  Because of this, I’ve been reflecting back on how the birth of Oracle’s Unified method - OUM came about.

As the Release Director of OUM, I’ve been honored to package every method release.  No, maybe you’d say it’s not so special.  Of course, anyone can use packaging software to create an .exe file.  But to me, it is pretty special, because so many people work together to make each release come about.  The rich content that results is what makes OUM’s history worth talking about.  

To me, professionally speaking, working on OUM, well it’s been “a labor of love”.  My youngest child was just 8 years old when OUM was born, and she’s now in High School!  Watching her grow and change has been fascinating, if you ask her, she’s grown up hearing about OUM.  My son would often walk into my home office and ask “How is OUM today, Mom?”  I am one of many people that take care of OUM, and have watched the method “mature” over these last 6 years.  Maybe that makes me a "Method Mom" (someone in one of my classes last year actually said this outloud) but there are so many others who collaborate and care about OUM Development.

I’ve thought about writing this blog entry for a long time just to reflect on how far the Method has come. Each release, as I prepare the OUM Contributors list, I see how many people’s experience and ideas it has taken to create this wealth of knowledge, process and task guidance as well as templates and examples.  If you’re wondering how many people, just go into OUM select the resources button on the top of most pages of the method, and on that resources page click the ABOUT link.

So now back to my nostalgic moment as I finished release 5.6 packaging.  I reflected back, on all the things that happened that cause OUM to become not just a dream but to actually come to fruition.  Here are some key conditions that make it possible for each release of the method:

  • A vision to have one method instead of many methods, thereby focusing on deeper, richer content
  • People within Oracle’s consulting Organization  willing to contribute to OUM providing Subject Matter Experts who are willing to write down and share what they know.
  • Oracle’s continued acquisition of software companies, the need to assimilate high quality existing materials from these companies
  • The need to bring together people from very different backgrounds and provide a common language to support Oracle Product implementations that often involve multiple product families

What came first, and then what was the strategy?

Initially OUM 4.0 was based on Oracle’s J2EE Custom Development Method (JCDM), it was a good “backbone”  (work breakdown structure) it was Unified Process based, and had good content around UML as well as custom software development.  But it needed to be extended in order to achieve the OUM Vision.

What happened after that was to take in the “best of the best”, the legacy and acquired methods were scheduled for assimilation into OUM, one release after another.  We incrementally built OUM.  We didn’t want to lose any of the expertise that was reflected in AIM (Oracle’s legacy Application Implementation Method), Compass (People Soft’s Application implementation method) and so many more.

When was OUM born?

OUM 4.1 published April 30, 2006.  This release allowed Oracles Advanced Technology groups to begin the very first implementations of Fusion Middleware.  In the early days of the Method we would prepare several releases a year.  Our iterative release development cycle began and continues to be refined with each Method release.  Now we typically see one major release each year.

The OUM release development cycle is not unlike many Oracle Implementation projects in that we need to gather requirements, prioritize, prepare the content, test package and then go production.  Typically we develop an OUM release MoSCoW (must have, should have, could have, and won’t have) right after the prior release goes out.   These are the high level requirements.  We break the timeframe into increments, frequent checkpoints that help us assess the content and progress is measured through frequent checkpoints.  We work as a team to prioritize what should be done in each increment. Yes, the team provides the estimates for what can be done within a particular increment.  We sometimes have Method Development workshops (physically or virtually) to accelerate content development on a particular subject area, that is where the best content results. As the written content nears the final stages, it goes through edit and evaluation through peer reviews, and then moves into the release staging environment.  Then content freeze and testing of the method pack take place.  This iterative cycle is run using the OUM artifacts that make sense “fit for purpose”, project plans, MoSCoW lists, Test plans are just a few of the OUM work products we use on a Method Release project.

In 2007 OUM 4.3, 4.4 and 4.5 were published.  With the release of 4.5 our Custom BI Method (Data Warehouse Method FastTrack) was assimilated into OUM.  These early releases helped us align Oracle’s Unified method with other industry standards

Then in 2008 we made significant changes to the OUM “Backbone” to support Applications Implementation projects with that went to the OUM 5.0 release.  Now things started to get really interesting.  Next we had some major developments in the Envision focus area in the area of Enterprise Architecture.  We acquired some really great content from the former BEA, Liquid Enterprise Method (LEM) along with some SMEs who were willing to work at bringing this content into OUM.  The Service Oriented Architecture content in OUM is extensive and can help support the successful implementation of Fusion Middleware, as well as Fusion Applications.

Of course we’ve developed a wealth of OUM training materials that work also helps to improve the method content.  It is one thing to write “how to”, and quite another to be able to teach people how to use the materials to improve the success of their projects.  I’ve learned so much by teaching people how to use OUM.

What's next?

So here toward the end of 2012, what’s in store in OUM 5.6, well, I’m sure you won’t be surprised the answer is Cloud Computing.   More details to come in the next couple of weeks! 

The best part of being involved in the development of OUM is to see how many people have “adopted” OUM over these six years, Clients, Partners, and Oracle Consultants.  The content just gets better with each release.  

I’d love to hear your comments on how OUM has evolved, and ideas for new content you’d like to see in the upcoming releases.

Thursday Aug 23, 2012

Reflections on the Agile2012 Conference

Last week, I had the great fortune to attend the Agile2012 conference at the lovely Gaylord Texan Hotel in Grapevine, TX, just a short drive (at least by Texas standards) from where I live.  Overall, the conference was a great experience and I am very glad to have had the opportunity to participate.   I picked up a number of ideas for tools and techniques that will most likely find their way into OUM at some point.   It was encouraging to hear real-world agile success stories described at a number of the sessions and to see the passion and energy from the conference attendees.  Discussions with fellow agile practitioners were extremely valuable, as is usually the case at such conferences.  I plan to include some of these topics in future blogs.

I found that many of the ideas we promote in OUM about balancing agility and discipline are now becoming increasingly in vogue within the agile community.  Teams are finding it valuable to produce plans and documentation at the appropriate level depending on the particular project situation.   Keeping an eye on enterprise architecture and establishing a solid technical architecture was a common theme in several of the sessions I attended.  Whether people use the term iteration or sprint, there was a true appreciation of how the agile approach to managing projects drives out risks and identifies possible errors early on in the project.  To sum it up, I got the impression from the conference that there is a growing recognition of the benefits of flexible and scalable methods like OUM.

I heard several people mention that the Wild West days of agile are coming to an end.  It is my theory that the wider approval of agile techniques, coupled with the growing practice among agile teams to apply a certain amount of discipline, is probably leading to the Wild West impression fading away into the sunset.  In any case, I thought the phrase was rather appropriate given the venue.

What do you think?  Are the Wild West days of agile coming to an end?  Are those days a perception, reality or both?

Tuesday May 08, 2012

OUM and PMI's Pulse of the Profession: The Fifth In a Series

Welcome to the fifth (and final) blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #4: Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets.  That entry highlighted how the OUM Training Program prepares project team members in various roles to be effective on an OUM project.

In this blog entry we will look at PMI’s Key Finding #5: Despite tight economic conditions, organizations have been and will continue to increase their focus on benefits realization success metrics.  PMI’s research shows project/program managers must maintain a focus on the strategic objectives of the project.  Anyone who has been on a project knows it is not easy to keep the big picture in mind when we are caught up in our day-to-day tasks.  So in this blog entry we will take a look at some of the key elements in OUM that help keep projects aligned with the organization’s strategic goals.

Whenever we talk strategy in OUM we turn our attention to the Envision Focus Area.  The development and maintenance of enterprise level IT strategy, architecture, and governance done in Envision helps to ensure IT delivery is in alignment with the organization’s strategy.  Ideally, every enterprise should be executing the processes in Envision or similar processes. 

I am going to get on my soapbox at this point and say, because the processes in Envision provide the glue between the business and IT strategies, true benefits realization will be very difficult (or nearly impossible)to achieve without an Envision or similar engagement.  We discussed in the first blog entry of this series how Envision helps ensure projects will align with an organization’s objectives by providing the processes to support effective portfolio management.   We know that organizations who focus only at the project level will wind up with a collection of stovepipe projects that have limited ability to address the organization’s strategic needs or provide return on investment.  We also know that project teams starting out without an enterprise IT strategy and architecture, or the appropriate IT governance in place will often find it necessary to gather enough information to establish the project’s objectives, scope, and estimates for the solution.  This can cause significant project delays and possibly lead to costly re-work. 

In order to understand the connection between the artifacts produced in the Envision Focus Area and how they relate directly to the tasks in the Implement Focus Area, project teams should be aware of the Envision Touch Points found in the OUM Method Overview page.  These touch points are potential prerequisites from Envision work products to Implement tasks.  As we know, an Envision engagement does not always precede an Implement engagement and, therefore, these touch points are not always available to the project as artifacts.  The project team must then determine the degree to which the Envision tasks should be executed to generate the necessary information to proceed.

The project manager should also look to the Envision artifacts when establishing the project structure to make sure the project is set up to achieve the expected benefits of the project.  During the Project Start Up phase of the OUM Manage Focus Area, resources are allocated to achieve specific objectives, satisfy needs, and set expectations through a planned and organized approach.   The project manager should start with the enterprise IT strategy and governance when formulating this approach, and then document the approach as part of the Project Management Framework (the precursor to the Project Management Plan).

As you can tell, I am a big fan of Envision.  I put a great deal of value in this focus area of OUM because I have seen so many projects that benefited by having a view of the big picture.  But, if you disagree with my assessment of how important enterprise-level work is to benefits realization, please let me know in the comments section.  For some really good advice on the role of an Oracle Enterprise Architect and how they can benefit a project, check out a blog entry written by my colleague called “When to Call an Oracle Enterprise Architect”.

This wraps up the series on PMI’s 2012 Pulse of the Profession.  I hope you enjoyed reading these entries as much as I did writing them.  It’s been a great opportunity to demonstrate how OUM is in-tune with leading industry trends.  The series has generated quite a bit of inspiration for future blog entries. So please keep watching this blog, as well as our LinkedIn Group and Twitter for OUM information, tips, and techniques.  If you have a suggestion for a future blog entry or have a question, you can reach us at ominfo_us@oracle.com.

Tuesday Apr 17, 2012

OUM and PMI's Pulse of the Profession: Second in a Series

Welcome to the second of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #1: Tight economic conditions will continue to force the issue of strong project portfolio management.   We saw how project portfolio management is supported in OUM by the Envision and Manage Focus Areas.   In this blog entry we will take a look at PMI’s Key Finding #2: The desire for organizational agility will also lead to increased use of iterative and/or incremental project management methods such as agile and extreme. 

The first thing we need to do is define “organizational agility”.  If you do a search on the term, you come up with a wide variety of definitions which essentially boil down to this: the ability an organization to recognize changes (whether they be threats or opportunities), and respond to these changes in a timely, cost-effective, and appropriate manner.  Notice there are two parts to the definition:  part one is the ability to recognize the need for change; the other part is being effective in the response to the change.

If an organization as a whole is striving to be agile, it makes sense that their IT organization must also be agile. In many cases the IT organization not only supports the overall organization’s agility, but drives it by introducing enabling tools and technologies.  On the other hand, IT can also inhibit an organization’s ability to be agile by being late to deliver IT solutions, slow to react to change, and/or not being in tune with the business’s changing requirements.

Agile methods, like OUM, help to enable IT and organizational agility because they are designed to significantly reduce project risk, and deliver value much earlier in the lifecycle than traditional waterfall methods.  The time it takes to get working software into users hands can be accelerated by releasing important features first, and pushing off the lower priority items to later releases.  This in turn, provides a rapid improvement of an organization’s capabilities and/or competitive position.  Agile methodologies also encourage regular involvement by business stakeholders, which helps ensure the IT solutions match the organization’s objectives.

As PMI indicates in Key Finding #2, iterative and incremental development is at the heart of any agile methodology.  OUM recognizes the advantages of an iterative and incremental approach to development and deployment of information systems.  Any of the tasks within OUM may be iterated. Tasks may be iterated to increase quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand the work products on the basis of user feedback.

In addition to having an agile iterative and incremental development approach, OUM also:

Is flexible and scalable – OUM is designed to support a broad range of project types. As such, it must be flexible and scalable. The appropriate point of balance for a given project will vary based on a number of project risk and scale factors. The method has been developed with the intent that the approach for a given project be “built up” from a core set of activities to implement an appropriate level of discipline, rather than tailored down.

Allows for frequent customer interaction and feedback – OUM encourages regular sessions with stakeholders to review and confirm priorities, and ensure the project continues to meet the overall objectives.  Through several prototyping and testing tasks, business stakeholders are given the opportunity to review the development work completed to that point, and provide feedback in time to catch missed requirements and/or possible errors.

Employs a layered planning approach – OUM recognizes that plans need to be scalable for different project sizes and complexity, and contain the right level of detail for the current planning horizon.  The layered approach to planning an OUM project allows project teams to take an agile approach to their immediate project tasks, while keeping a focus on the major milestones, controls, and objectives of the project. 

Encourages the use of an empowered team – OUM encourages cross-functional and technical team training and knowledge sharing.  In addition, the use of OUM’s common language and visual models (use cases and business process models) throughout the project helps ensure the development team and other project stakeholders are on the same page, which promotes team communication and collaborative decision making.

Integrates testing throughout the development lifecycle – Testing in OUM starts early in the project, and developed components are integrated and tested as an integrated set as soon as possible. This allows for early discovery of errors that eventually reduces the risk of project delays that often are caused by heightened error detection at the end of the project.

Promotes an architecture-centric approach –  People will sometimes question whether spending time and energy on architecture is compatible with an agile approach.  The answer is that a robust architecture is crucial to the project’s success since it is the blueprint upon which requirements are transformed into a working system.   Poor architecture decisions can result in software that is not stable, is unable to support business requirements, could require substantial re-work, may not accommodate future development, or could even prevent the application from working properly in a production environment.  Nothing about poor architecture sounds too agile, does it?

I could go on for a while about OUM’s agile underpinnings; the bottom line is that OUM supports all kinds of projects – from the very lean and adaptable, to those that require more rigor and discipline.  If you want to find out more about how OUM can be applied in an agile manner, check out the Scrum guidance which includes the “Managing an OUM Project Using Scrum” whitepaper, User Story Task and Template, Product Backlog and Sprint Backlog Templates, and Scrum to OUM Mapping.  For information on OUM’s layered approach to project planning, the “Planning a Project Using OUM” whitepaper contains guidance on OUM’s layered approach to project planning.  The OUM Read Me First is a valuable reference if you want to become familiar with the method’s philosophy, key concepts, and principles.  Finally, if you have not already done so I recommend reading an excellent blog entry written by my colleague called Build Up or Tailor Down.

Stay tuned for the next blog entry in the series when we will explore PMI’s Key Finding #3:  As organizations continue to strive for agility, change management and project risk management will become even more important.

Thursday Jan 12, 2012

The Project Management Plan (PMP) in OUM - Creation and Evolution

According to the Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition, the Project Management Plan is defined as a formal, approved document that defines how the project is executed, monitored and controlled.  In OUM, the Project Management Plan (better known as the PMP) defines the overall project management strategies and approaches applied to the project.  Since the PMP is considered to be the most important artifact created by the project manager, it is important to understand how the PMP is created and evolved in OUM.

Creation

The creation of the PMP is started with the Project Management Framework in the task BT.070 – Create Project Management Framework, which is part of the OUM Manage Focus Area’s Project Startup Phase.  The project manager creates the Project Management Framework, along with the project sponsor and other stakeholders.  At this point in the project, the Project Management Framework represents the PMP at the strategic level.  In fact, the Project Management Framework can be thought of as the initial or high-level version of the PMP. 

Evolution and Refinement

After the Project Management Framework is created early in the Project Start Up phase, it is then used as a key prerequisite for each of the OUM Manage process plans – Scope Change Management Plan, Quality Management Plan, Risk Management Plan, etc .  The PMP is refined in an iterative fashion through input and approval from the various project stakeholders and subject matter experts as the project progresses.  This means the PMP is not a static document, but is evolved to become the project management artifact that details the tools and approach for each of the 13 OUM Manage processes.

Need More Info?

For more information on how the PMP evolves from the Project Management Framework, check out the BT.070 Task - Create Project Management Framework in OUM 5.5.

Thursday Oct 06, 2011

Iteration vs. Oscillation

What’s the difference between iteration and oscillation?  This is important distinction for an OUM practitioner to be able to articulate – that while OUM is indeed an iterative method; it does not mean you are endlessly oscillating on the same tasks like a washing machine stuck on the rinse cycle.   Since properly applying iterative development principles is vital to an OUM practitioner’s success, this blog explains why, in OUM, iteration doesn’t equate to oscillation.

WHAT IT MEANS TO BE ITERATIVE:  Let’s first understand iterations. In OUM (or any other iterative approach), you divide each phase into periods of time, usually from 2 to 6 weeks (some prefer 2~4 weeks), called iterations. During each of these periods, the team executes tasks in order to achieve the iteration's goal(s).  Therefore, the term, "iterative" means that work on an OUM project is divided into a series of "iterations" that are essentially run as mini-projects.

ARE WE THERE YET?  Now we have a solid understanding of iterations, but it still doesn’t completely explain why the project team isn’t oscillating into eternity.  The key here is that “iterative development” also includes the concept of growing the system incrementally.

WHAT IT MEANS TO BE INCREMENTAL:  Turning our attention to incremental, this means that the system is developed in chunks, iteration by iteration.  Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.  At the end of an iteration, the resulting increment of functionality is presented to users and requirements are re-evaluated so as to plan the next iteration.

PUTTING IT ALL TOGETHER:  Putting this all together, “iterative development” in OUM means that the system is developed through a series of mini-projects (iterative), and in smaller portions at a time (incremental), allowing the project team to take advantage of what was learned during earlier development, and incorporate feedback from project stakeholders.  As the project progresses, the emphasis given to a particular task shifts from phase to phase so that the appropriate phase milestones are met, and ultimately the project’s overall goals are achieved.

ARE WE THERE YET (AGAIN)?  You can see that an OUM project team will be working in iterations, growing the software increment by increment, and finally achieving a stable solution that real end-users can employ.  This is much different than being caught in an endless re-run of the movie “Groundhog Day”, forever oscillating on the same tasks; achieving nothing. Now that you’ve read this blog entry, I’d love to hear your thoughts on the differences between iteration and oscillation.
About

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

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds