Monday Apr 09, 2012

OUM and PMI's 2012 Pulse of the Profession: The First in a Series

Taken your pulse lately?  Recently, PMI released their 2012 Pulse of the Profession which contains five key findings based on the results of their global survey:

  1. Tight economic conditions will continue to force the issue of strong project portfolio management.
  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.
  3. As organizations continue to strive for agility, change management and project risk management will become even more important.
  4. Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets.
  5. Despite tight economic conditions, organizations have been and will continue to increase their focus on benefits realization success metrics.

Since of PMI’s 2012 key findings are highly relevant to the ever expanding Oracle ecosystem, I thought it would be beneficial to put together a series of blog entries to discuss each of PMI’s key finding in the context of OUM.  Through the entries, I hope you find some useful tips and techniques you can apply to your projects right away.

Let’s jump into Key Finding #1:  Tight economic conditions will continue to force the issue of strong project portfolio management, which is defined by Wikipedia as “methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics.” 

We all know there has never been a time when organizations intentionally threw money away on frivolous projects.  During times of constrained and uncertain economic conditions, it is even more critical to make sure money is allocated to projects and programs which will provide the most business value and highest return on investment.  When guidance is needed for project identification and prioritization, we look to where projects are born in OUM:  The Envision Focus Area.

The Envision Focus Area comprises the areas OUM that deal with development and maintenance of enterprise level IT strategy, architecture, and governance.  Every project that affects an organization’s IT landscape should have its origins here.   Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects further supported by the Manage and Implement focus areas.

I think the Envision Focus Area is one of the areas that make OUM unique in that it addresses the business at the enterprise level, rather than just at the tactical project level.  You can read more about the Envision Focus Area and its touch points to the Implement and Manage Focus Areas in the OUM Overview section, as well as by reading the detailed content in the Envision view itself.  

This brings us to the Manage Focus Area, which is the standard framework and reference guide that provides a consistent and repeatable approach for managing Oracle-related information technology projects.  The Manage Focus Area includes guidance for managing both projects and programs.  While there is no substitute for good project management skills, Manage is essentially a tool that can be used to facilitate and support the program or project management process.  For more details about Manage and its relationship to Envision and Implement, check out the OUM Overview section and the in-depth guidance found in the Manage view.

Stay tuned for the next blog entry in the series which will focus on 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.  In the meantime, please provide your feedback on your experience with the Envision and Manage Focus Areas.

Monday Mar 19, 2012

Developing an Implementation Plan with Iterations by Russ Pitts

Developing an Implementation Plan with Iterations by Russ Pitts 

Ok, so you have come to grips with understanding that applying the iterative concept, as defined by OUM is simply breaking up the project effort you have estimated for each phase into one or more six week calendar duration blocks of work.

Idea being the business user(s) or key recipient(s) of work product(s) being developed never go longer than six weeks without having some sort of review or prototyping of the work results for an iteration…”think-a-little”, “do-a-little”, and “show-a-little” in a six week or less timeframe…ideally the business user(s) or key recipients(s) are involved throughout.

 

You also understand the OUM concept that you only plan for that which you have knowledge of. The concept further defined, a project plan initially is developed at a high-level, and becomes more detailed as project knowledge grows. Agreeing to this concept means you also have to admit to the fallacy that one can plan with precision beyond six weeks into a project…Anything beyond six weeks is a best guess in most cases when dealing with software implementation projects.

 

Project planning, as defined by OUM begins with the Implementation Plan view, which is a very high-level perspective of the effort estimated for each of the five OUM phases, as well as the number of iterations within each phase.

 

You might wonder how can you predict the number of iterations for each phase at this early point in the project. Remember project planning is not an exact science, and initially is high-level and abstract in nature, and then becomes more detailed and precise as the project proceeds.

 

So where do you start in defining iterations for each phase for a project?

 

The following are three easy steps to initially define the number of iterations for each phase:

 

Step 1 => Start with identifying the known factors…

 

…Prior to starting a project you should know:

 

 <!--[if !supportLists]-->· <!--[endif]-->The agreed upon time-period for an iteration (e.g 6 weeks, or 4 weeks, or…) within a phase (recommend keeping iteration time-period consistent within a phase, if not for the entire project)

 

<!--[if !supportLists]-->· <!--[endif]-->The number of resources available for the project

 

<!--[if !supportLists]-->· <!--[endif]-->The number of total number of man-day (effort) you have estimated for each of the five OUM phases of the project

 

<!--[if !supportLists]-->· <!--[endif]-->The number of work days for a week

 

Step 2 => Calculate the man-days of effort required for an iteration within a phase…

 

Lets assume for the sake of this example there are 10 project resources, and you have estimated 2,536 man-days of work effort which will need to occur for the elaboration phase of the project. Let’s also assume a week for this project is defined as 5 business days, and that each iteration in the elaboration phase will last a calendar duration of 6 weeks. A simple calculation is performed to calculate the daily burn rate for a single iteration, which produces a result of…

 

((Number of resources * days per week) * duration of iteration) = Number of days required per iteration

 

((10 resources * 5 days/week) * 6 weeks) = 300 man days of effort required per iteration

 

 

Step 3 => Calculate the number of iterations that can occur within a phase

 

Next calculate the number of iterations that can occur for the amount of man-days of effort estimated for the phase being considered…

 

(number of man-days of effort estimated / number of man-days required per iteration) = # of iterations for phase

 

(2,536 man-days of estimated effort for phase / 300 man days of effort required per iteration) = 8.45 iterations, which should be rounded to a whole number such as 9 iterations*

 

*Note - It is important to note this is an approximate calculation, not an exact science. This particular example is a simple one, which assumes all resources are utilized throughout the phase, including tech resources, etc. (rounding down or up to a whole number based on project factor considerations). It is also best in many cases to round up to higher number, as this provides some calendar scheduling contingency.

 

Thursday Mar 01, 2012

When to call an Oracle Enterprise Architect in on your project

When you aren’t sure about your physical health, what do you do?  Well, you may call in a doctor, maybe even a “specialist”.

As a Project Manager, and a PMP, I understand the need to “protect the project”.  Risks should be mitigated early on so that they don’t become issues.  So “When do I call in an Oracle Enterprise Architect (OEA) on my project?”  What signs should I look for to indicate that an OEA is needed?

Recently, I’ve had the opportunity to work with Oracle Consulting PM’s, Customers and Partners who saw the value of having an Oracle Enterprise Architect as a “trusted advisor” to the Project or Program Manager.   But some Project Managers may not be aware of what an OEA does, or when it is advisable to call an OEA in on a project.

The Oracle Unified Method (OUM) includes an Oracle Enterprise Architecture Development Process (OADP) View.  This view includes only tasks from the OUM Envision focus area. However, many of these tasks are “touch points” or prerequisites to tasks in the Implement focus area.  The expertise of an OEA is important on a Software Implementation project.

Did you know that the OADP View in OUM Envision was authored by a global group of Oracle Enterprise Architects (OEA)?  These subject matter experts were some of the earliest contributors to OUM and they continue to refine the guidance that OUM provides for Enterprise Architecture.


What is the role of an Oracle Enterprise Architect
An OEA does five specific things – that are unique to the OEA role:

  • Thinks in time (Current State / Future State / and more importantly – Intermediary or Transitional State)
  • Examines “Multidimensional Processing” (People, Process, Strategy and Technology)
  • Brings together Multi-pillar Architectures (Apps, Tech,  Hardware and Software)
  • Performs “Environmental Contextualization” – The fit of the System Under Discussion (SuD) into overall ecosystem – not just designing the architecture in and of itself
  • Provides Trade-off Analysis for Best-fit architecture (Architecture alternatives: balance Business, Organizational, Financial and Technical factors)

An OEA participates in specialized training that examines the current state architecture, discovers the Business Objectives and Strategy of the Enterprise and then develops future state architectures and practical roadmaps, that could be used to achieve those business objectives.


When to call an Enterprise Architect
So, under what conditions, does an Oracle Software implementation project or program benefit from the role of an Oracle Enterprise Architect (OEA)?

What are some of the characteristics of projects in the Enterprise IT Portfolio that would gain value and produce quantifiable return on investment, thereby truly benefitting from an OEA as a trusted advisor?

In general, a project that has a high level of complexity could benefit from an OEA.  This complexity could be technical, architectural or business, or some combination these.

Here is a list of some common project scenarios that provide increased benefit to the business by utilizing the skills of an Oracle Enterprise Architect as an implementation project trusted advisor:

  • Project includes multiple Oracle products - from different product families
  • Large scale combined application and technology projects
  • Project duration is more than 1 year
  • Project budget is in excess of $1M
  • Project includes integration with more than ten legacy systems
    Composite Applications includes several of those WebCenter Portals, Service Oriented Architecture, BPM Processes, Enterprise Security and Enterprise Applications such as CRM, Financials or HR.


Of course many software implementation scenarios could benefit from an OAE as a trusted advisor.  The above list includes just a few of the project scenarios that really should consider including an OEA.

Value of Enterprise Architecture and an OEA to the project
Having a framework (such as Oracle's OEAF) and a well defined process for Enterprise Architecture development (OADP) is of critical importance. Together they help produce artifacts (work products) that ultimately align technology goals and initiatives to business strategy.

An OEA participates in specialized training that examines the current state architecture, discovers the Business Objectives and Strategy of the Enterprise and then develops future state architectures and practical roadmaps, that could be used to achieve those business objectives.

Enterprise architecture is the alignment of IT and IT assets to support business strategy. By achieving the business strategy of the enterprise, we have increased the business value of the enterprise.  In order to really identify the true value of enterprise architecture we need to understand how we measure business value and develop a portfolio of implementation projects that help us reach achievable and measurable goals.

The OEA contributes to the success of a defined business strategy.  They help Software implementation project teams execute on a roadmap.  Each of these projects is part of a portfolio of implementation projects that combine to realize the defined future state architecture.  During the execution of the roadmap, they help to deliver the IT initiatives that provide measurable returns to the business.

The OEA acts as an advisor to the Project or Program Manager.  They keep the various functional partitions in alignment with the technical partitions, thereby assuring the OUM Principle of remaining “Architecture Centric”.

As the OEA examines the individual organizational units within the enterprise they can identify how the unit has performed by quantitatively measuring achievable goals as defined by the business for each unit. True business value may seem to be subjectively measured.  However, looking at the requirements of the System under Discussion (SuD) and determining the impact to the business with measurable goals, is more quantifiable.

As a project manager, I can examine the project profile and determine if it meets the characteristics outlined above, if it does… Well, who am I going to call?  I will call an Oracle Enterprise Architect (OEA).

What are your thoughts on this topic?

For more information about Oracle Enterprise Architecture Services, look on http://www.oracle.com/us/products/consulting/enterprise-architecture-services/index.html 

Many thanks to Ajay Ailawadhi and Paul Silverstein - Oracle Consulting Advanced Technology Services, ESG organization for contributing to this blog entry.

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.

Wednesday Dec 14, 2011

Build Up Or Tailor Down?

OUM is intended to be highly scalable. In our industry today we hear lots of buzzwords around Agile or Agility. We see many methods in today’s marketplace that have adopted an agile approach to software development. The Global Methods team is in strong agreement with the tenets put forth in the “Manifesto for Agile Software Development.” We also see a debate in our industry about agility versus discipline which has been well framed in the book “Balancing Agility and Discipline: A Guide for the Perplexed” by Barry Boehm and Richard Turner.

 

To help OUM’s users determine just how much of OUM they should employ on a given project, we have adopted many of the philosophies and conclusions put forth in the book. It has helped to guide us in developing OUM and also in developing the guidance related to using OUM. By Boehm and Turner’s definition, at its highest level, OUM is a plan-driven method, which could be tailored down by an expert, to fit a particular situation. However, as the book points out, non experts tend to play it safe under these circumstances, and often tend to use to much or all of a method “at considerable unnecessary expense.”

Therefore, we’ve taken the advice of Boehm and Turner and adopted the philosophy of “Build it Up – Don’t Tailor it Down.” OUM’s Implement Core Workflow, along with OUM’s diverse set of views, are intended to support this philosophy.

In addition to the workflow and views, we advise you to follow 4 steps when considering the tasks to include in your OUM based workplan.

The first step is to start from a core set of tasks. We recommend that you consider using the OUM Implement Core Workflow for this purpose along with an OUM view that best matches the needs of your project. Remember, though, that the views tend to be a superset of tasks related to a particular solution, discipline, or technology. Therefore, the core workflow and views should be used together to achieve the right balance for your project.

Further information on tailoring OUM can be found in this White Paper: http://my.oracle.com/content/native/cnt723708

An external version of this White Paper will be published early in 2012 along with recorded training for Oracle Consulting, along with our Partner and Customer community. 

 

Wednesday Nov 23, 2011

Stakeholder Management in OUM

Where is Stakeholder Management in OUM?  Stakeholder Management typically falls into the purview of the Project Manager, which means much of the associated guidance is found in the OUM Manage Focus Area (a.k.a. Manage).  There is also a good deal of content related to the discipline of Stakeholder Management contained in the Implement Focus Area (a.k.a Implement).

There is no process in Manage named Stakeholder Management, but this “touch point” can be found in a variety of other processes including Bid Transition (BT), Communication Management (CMM) and Organizational Change Management (OCHM).

         Stakeholder Management starts in the Bid Transition process with Stakeholder Analysis.

         This Stakeholder Analysis is used to build the Project Team Communication Plan in the Communication Management process.

         Stakeholder Management should be executed during the Execution and Control phase.  For example, as issues are resolved, the project manager should take the action item to follow up with the affected stakeholders to ensure they are aware that the issue has been resolved.

       The broader topic of Stakeholder Management is also addressed very thoroughly in the Organizational Change Management process in the Implement Focus Area, which is a touch point to the Organizational Change Management process in Manage.

Check it out and let me know your thoughts!

Tuesday Nov 15, 2011

OUM is Flexible and Scalable

Flexible and Scalable

Traditionally, projects have been focused on satisfying the contents of a requirements document or rigorously conforming to an existing set of work products. Often, especially where iterative and incremental techniques have not been employed, these requirements may be inaccurate, the previous deliverables may be flawed, or the business needs may have changed since the start of the project. Fitness for business purpose, derived from the Dynamic Systems Development Method (DSDM) framework, refers to the focus of delivering necessary functionality within a required timebox. The solution can be more rigorously engineered later, if such an approach is acceptable. Our collective experience shows that applying fit-for-purpose criteria, rather than tight adherence to requirements specifications, results in an information system that more closely meets the needs of the business.

In OUM, this principle is extended to refer to the execution of the method processes themselves. Project managers and practitioners are encouraged to scale OUM to be fit-for-purpose for a given situation. It is rarely appropriate to execute every activity within OUM. OUM provides guidance for determining the core set of activities to be executed, the level of detail targeted in those activities and their associated tasks, and the frequency and type of end user deliverables. The project workplan should be developed from this core. The plan should then be scaled up, rather than tailored down, to the level of discipline appropriate to the identified risks and requirements. Even at the task level, models and work products should be completed only to the level of detail required for them to be fit-for-purpose within the current iteration or, at the project level, to suit the business needs of the enterprise and to meet the contractual obligations that govern the project.

OUM provides well defined templates for many of its tasks. Use of these templates is optional as determined by the context of the project. Work products can easily be a model in a repository, a prototype, a checklist, a set of application code, or, in situations where a high degree of agility is warranted, simply the tacit knowledge contained in the brain of an analyst or practitioner. For further reading on agility, see Balancing Agility and Discipline: A guide fro the Perplexed.

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.

Wednesday Sep 14, 2011

Why not use “just enough” OUM?

Sometimes I hear people say, “Oh, OUM is great, but I’m not sure I can use it for the work I’m doing”. I ask “Why not?”, often I hear one of three answers;

  1. I’m working as part of a staff augmentation contract, and there really isn’t a formal “project” for me within the Enterprise.
  1. The Enterprise has chosen to use their internal method for this project.
  1. Oracle Consulting is not leading the project or the Partner leading the project for the Enterprise is using a proprietary method.

Of course, there are many other reasons why someone chooses not use OUM for Oracle product implementations, or other work with oracle products.  These responses make me ask the question “Why not”?   

The Enterprise is using their internal method

Maybe the Enterprise has an “in house” method they’d like to use.  Of course, not every Oracle product implementation project requires that you make extensive use of OUM. If the other method seems capable of helping identify and manage risks, improves repeatability and quality, and encourages knowledge capture and reuse, maybe you don't need OUM. 

However there may be situations, where you realize that the method doesn’t have adequate support for the type of work you’re doing.  What if the project includes a technical requirement to implement a Service Oriented Architecture the first time?  Perhaps the method you’ve been asked to use isn’t SOA enabled?  If you wanted to SOA Enable that method you might suggest that the Enterprise look at OUM’s SOA Engineering Planning View.  You might simply review the OUM SOA Core workflow view to determine additional tasks that you might recommend as candidates for the project plan using “just enough” OUM. 

An Oracle Partner leading the project using a proprietary method or you are an Oracle Consultant assigned as an augmentation to staff.

There should be some agreement between the stakeholders the consultant(s) and the partner, regarding the work they are to do on the project.  So I ask, why couldn’t you use “Just enough” of OUM to make sure you have a solid agreement on working together on the project, and the assigned resource responsibilities?  Could you use a portion of the OUM BT.070 Project Management Framework to agree and document how the project is organized?

If you’re assigned to do some work within the Enterprise but not as part of a large project, maybe you could prioritize the work.  You could use a MoSCoW list (RD.045) to list out the things that you Must do, Should do, or Could do, in your role.  How about using a Business and System Objectives (RD.001)?  this could improve communication and discuss with the stakeholders regarding the work, you are being asked to do (and what you won’t be doing).  No matter how big the job, scoping the effort and having an agreement will often avoid misunderstandings.  It also gives a definition of what it looks like to call the work “finished”.

What if you’re writing some custom components that are fairly complex and architecturally significant?  Can you gather the detailed functional requirements using some OUM?  Could you prepare a Use Case Model (RD.023 Use Case Diagram and RD.024 Use Case Details) just to verify your requirements?  Maybe you don’t need a detailed “fully dressed” use case.  Perhaps a high-level use case would work.  After all, you may need to develop some test scripts, right?  Why not use the use case details to get to the test case details.  Why not start with the answers to the test, and then develop the custom components, extensions, or integrations?

When you use OUM think about using “just enough” to facilitate communication, clarify requirements, and protect the project. You’ll find yourself using the portions of OUM that make sense for the work at hand.  After all, it isn’t an all or nothing question.  As you’ve read before in the OUM Read Me First “Do not serve the method; make it serve you.”

I’ve chosen to highlight only a few OUM tasks in this blog entry there are many others that could be considered in addition to these depending on your scenario.

Using too much of a method, is just as bad as not using any method at all.   What are your thoughts on this topic?  I look forward to reading your ideas and suggestions.

Monday Aug 15, 2011

The Tree

 

A couple of weekends ago, my wife and I were out for a bicycle ride on the Washington & Old Dominion (W&OD) - a paved, multi-use trail that stretches 45 miles from Washington, D.C. to Purcellville, VA.

We were westbound on a section of the trail between Route 7 and Dry Mill Rd. We were coming up behind a runner when the runner stopped suddenly and looked up. The upper two-thirds of a dead locust tree crashed down across the path. The tree fell harmlessly to the ground, but lay across a section with high-sloped sides. The tree had completely blocked the trail. Our initial attempts made it obvious that we didn't have enough muscle power to move the 10-inch diameter main trunk.

Soon other cyclists and runners began to arrive. Most began to dismount - except one guy on a shiny new $5K+ bike who didn't seem interested in helping. Ideas were quickly tossed back and forth about how to get the thing out of the way. I even heard my wife say something like, "This tree isn't going to get moved unless everyone helps." (wink, wink, nudge, nudge…).

As we organized to lift the main trunk, we noticed that part of the trunk was covered with a vine. It didn't look like poison ivy, but you never know. One woman said that she wasn't allergic to poison ivy, so she'd lift that section. One person with a bad back volunteered to clear smaller debris. By working together, in 10 minutes we had cleared that entire mess and we were back on our machines.

As we rode up the trail, we talked about what we had observed. We chuckled about the able-bodied guy who seemed willing to stand there and watch everyone else clear the path for him. However, for the most part we were impressed by the way this ad hoc team had worked together.

Of course, I began to pontificate about how this experience was an analog to software projects. We had been part of a self-organizing team. Each participant had different strengths and had contributed where they were best able. Some used their strength to lift. Some contributed their immunity. Others came behind and cleaned up. This simple project hadn’t required a detailed plan, but someone had worked to remove obstacles (i.e. "This tree isn't going to get moved unless… ").

If we’d had many trees to move, we probably would have wanted a plan to tell us which trees to move and when. We would have wanted to be able to tell the W&OD trail users when they would be able to use each section of the trail. We might have organized a brief planning meeting before moving each tree to be sure that we were being as efficient as possible.

To be sure we were on track, we would periodically ask everyone to briefly describe what they had done, what they were planning to do, and what was stopping them from being effective. That might have allowed us to discover that one team member was worried about scratching their new bicycle, but we certainly would have been able to understand everyone's contribution.

Historically, humans have cooperated very effectively to solve problems. That's one of the things that has allowed us to survive as a species. When the problems are more complex, we've learned that it's important that someone create a plan so that things get done in the proper order, etc. However, I think we would also agree that sometimes we have fallen into the trap of focusing too much on the plan and not enough on the people.

That’s why even when we're doing large, complex things it's essential that we make use of some of the same basic techniques that have worked on ad hoc projects.

  • Work to a high level plan (10 trees in 3 hours, trail cleared by 6 pm)
  • Employ short planning horizons (finish the current tree before starting the next tree)
  • Prioritize work (clear trees at mile markers 4, 6 and 8.5 first)
  • Employ self-organized teams (let the team decides how to clear each tree)
  • Leverage individual strengths (take advantage of Patty’s poison ivy immunity and Fred’s ability to clear leaves very quickly)
  • Improve the process (For the next tree, let’s be sure to…)
  • Give everyone a brief chance to be heard ("I've cleared the small branches, now I'm going to clear the leaves", "I'm worried about scratching my new bike")
  • Designate someone to clear impediments ("Next time, I'll arrange for a safe place to lean your bicycle so it won’t get scratched")

I think that most agile practitioners would say - and I would agree - that agile software methods aren’t radically new or different. They’re simply a recognition and codification of the behaviors that have made humans successful as a species.

What do you think?

Tom

Thursday May 12, 2011

Make the Method Serve You

One bit of feedback that we sometimes hear about the Oracle Unified Method (OUM) is that it's too heavy or that it forces a project to produce too many documents. The implication is that using OUM is too costly. Of course, developing methods that makes it more expensive or difficult to implement Oracle products would be a disservice to Oracle's customers and in opposition to the mission of the Oracle Global Methods organization.

This sort of feedback indicates that the individual may not yet have had the opportunity to fully explore OUM and to understand the philosophical basis upon which it has been developed. When you look more closely, you'll find a number of things that tell the real story:
  • Views provide an initial pre-tailoring of the OUM materials (though still a superset).
  • Supplemental Guides provide further tailoring recommendations along with product or discipline specific guidance to accelerate projects.
  • The Implement Core Workflow view identifies core tasks at the heart of any project. It helps keep project teams focused on the essentials by providing a four-step process for building up a project plan.
  • Guidance around iterative and incremental project planning and for managing an OUM project using Scrum illustrate our ongoing commitment to supporting agile project management.
Even more basic than all of these is the OUM Read Me First. The Read Me First describes OUM's philosophical underpinnings. It supports our position that too much method can be as risky as too little and that what projects need is method support that is "fit for purpose" and "just enough."

Here is an excerpt
:
  • Do not serve the method; make it serve you. The purpose of methods is to identify and manage risks, improve repeatability and quality, and encourage knowledge capture and reuse. If you’re not going to need it, don’t do it.

  • OUM should be scaled to fit your project. You should do no more than is necessary to satisfy the requirements of the project and appropriately address risks. Be sure to not only think about which tasks you will do, but also consider the depth to which your project team will execute specific tasks during specific iterations. Under the proper circumstances, spending the time to simply consider a task can constitute executing that task.

  • The output of a task (a work product) need not be a document. OUM provides templates for many of its tasks. Use of these templates is optional. They should be used only when appropriate to the context of the project. Work products can just as easily be a model in a repository, a prototype, a set of application code, or even the tacit knowledge contained in the brain of a developer. (Yes! This is an appropriate way to work, under the right circumstances.) Written documentation should be produced only when it is essential for the project’s success or the future operation and maintenance of the resulting software system and the business it supports.

  • A focus on understanding the most significant risks and requirements of the system is more important than producing elegant models or perfect documents. For example, not every model needs to be fully attributed to adequately manage design or implementation risks. On the other hand, skipping tasks simply to save effort may be a false economy, especially when implementing sensitive or mission critical systems. Do just enough.

OUM needs to support a broad range of projects; from those which must be very predictive to those which would benefit from being very adaptive. To be predictive, OUM needs to include materials that enable it to support a "heavy" level of ceremony. However, experienced practitioners will recognize the need to use careful forethought and judgment to employ "just enough ceremony" and produce "just enough documentation" to support the characteristics of a specific project.

Click to read the entire OUM 5.4.0 Read Me First.

Meanwhile are you going to Make the Method Serve You? What is your approach?

Tom

Wednesday Feb 23, 2011

Valuing "Working Software over Comprehensive Documentation"

I subscribe to the tenets put forth in the Manifesto for Agile Software Development - http://agilemanifesto.org. As leader of Oracle's Methods team, that might seem a self-deprecating attitude. After all, the agile manifesto tells us that we should value "individuals and interactions" over "processes and tools." My job includes process development.

I also subscribe to ideas put forth in a number of subsequent works including Balancing Agility and Discipline: A Guide for the Perplexed (Boehm/Turner, Addison-Wesley) and Agile Project Management: Creating Innovative Products (Highsmith, Addison-Wesley). Both of these books talk about finding the right balance between "agility and discipline" or between a "predictive and adaptive" project approach.

So there still seems to be a place for us in creating the Oracle Unified Method (OUM) to become the "single method framework that supports the successful implementation of every Oracle product." After all, the real idea is to apply just enough ceremony and produce just enough documentation to suit the needs of the particular project that supports an enterprise in moving toward its desired future state.

The thing I've been struggling with - and the thing I'd like to hear from you about right now - is the prevalence of an ongoing obsession with "documents."

OUM provides a comprehensive set of guidance for an iterative and incremental approach to engineering and implementing software systems. Our intent is first to support the information technology system implementation and, as necessary, support the creation of documentation. OUM, therefore, includes a supporting set of document templates. Our guidance is to employ those templates, sparingly, as needed; not create piles of documentation that you're not gonna (sic) need. In other words, don't serve the method, make the method serve you.

Yet, there seems to be a "gimme" mentality in some circles that if you give me a sample document - or better yet - a repository of samples - then I will be able to do anything cheaply and quickly. The notion is certainly appealing AND reuse can save time. Plus, documents are a lowest common denominator way of packaging reusable stuff. However, without sustained investment and management I've seen "reuse repositories" turn quickly into garbage heaps. So, I remain a skeptic.

I agree that providing document examples that promote consistency is helpful. However, there may be too much emphasis on the documents themselves and not enough on creating a system that meets the evolving needs of the business.

How can we shift the emphasis toward working software and away from our dependency on documents - especially on large, complex implementation projects - while still supporting the need for documentation? I'd like to hear your thoughts.
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