OMS SafeHarbor

Connecting Software and Customers

Posts Tagged ‘Best Practices

Electronic Software Delivery – Best Practices Part 3 – Draw a picture

leave a comment »

You’ve got goals and stakeholders for your ESD project. Now, draw a picture.

Use whatever is comfortable, including the analog pencil and paper. The format doesn’t matter. Ignore buzzwords like UML, Flow, Process, BPM, etc. and ignore getting sucked into fancy diagramming tool choices. Draw the picture however you are comfortable. The diagram will change, guaranteed.

At OMS we go back-and-forth between system diagrams and activity diagrams.

Here’s an example of an activity box diagram we use to help get lubricate conversations about ESD.

Plan == Create == Build == Manage == Release == Entitle == Distribute == Support

The objective of this step is simply to outline areas of focus that are important to achieving the business outcomes you desire. This is not an implementation checklist, that will come later. This is the umbrella sketch of things your organization will think about (and do) that impact your digital distribution project.

If you prefer, you may wish to sketch the system, or infrastructure for your project. Inside the firewall, staging, testing, Customer facing, Partner facing are four good starting boxes. In other words, the where instead of the what that you will ultimately use. Again, don’t worry about what it looks like, just get it down on paper.

It make no difference, at this point, whether your perspective is process (what) or system (where). Just start drawing. You’ll find that these pictures will become the most used and discussed tools in your ESD project toolkit.

Electronic Software Delivery – Best Practices Part 2 – Stakeholders

with one comment

Last week we identified setting success metrics, up-front, as the single most important practice in any ESD program. Identifying the stakeholders who will affect or consume those metrics is the second step to ensuring ESD success.

Depending upon the size of your company, this may involve anywhere from three to thirty (yes thirty) or more people.

More often than not the first-pass at list of ESD stakeholders is limited to “Marketing” groups, or more specifically, those folks who “run the website”. Effective ESD programs include representatives from the internal organizations that create and produce the digital assets that you will be delivering.


Your ESD program and will be affected by when and how the asset is determined to be fit for distribution, or DONE. Once the asset is declared complete (functionally), the process of packaging, bundling, or turning that single asset into a salable and DELIVERABLE product begins. Only after this point do the presentation and DELIVERY functions come to the fore. Therefore you must include people from each of these domains in your ESD program.

Here are some titles ESD stakeholders we interact with

VP, Marketing
VP, Operations
VP, Customer Service
VP, Engineering
Director, Configuration Management
Director, Marketing IT
Director, Logistics
Director, Tech Support
Director, Licensing
VP, General Counsel
Export Compliance Manager
Director, Product Management

At OMS SafeHarbor we consider the stakeholder process so important, that when we engage a customer we specify by name, in the contract documents individuals from IT, Operations, Marketing, Customer Service and Engineering that have agreed to support the project and be accessible to the project/program team.

To build a successful ESD program you need to have your goals firmly understood, and your stakeholders clearly identified. Knowing what you are going to do, and who is going to help you is your down payment on ESD success.

Written by admin

April 7, 2010 at 11:43 am

Central Infrastructure – Common Goal or Common Enemy to Process Re-Engineering for Mergers and Acquisitions

leave a comment »

One of the themes that we find ourselves discussing with potential clients is that many of today’s largest software and technology companies are built based upon mergers and acquisitions. We usually find practical reminders of a company’s M&A history buried in the operations. Product management procedures and business rules are greatly influenced by a product’s early history. Product teams are used to doing things a certain way and for certain reasons, many because that’s the way it’s always been done. Product release processes in particular are usually built adhoc and out of necessity. They tend to grow as the business grows and generally do not scale well with a business’ success. They may be tolerable in smaller companies but as companies merge this becomes a real threat to the bottom line because of the multiplier effect.

For the same reason why companies need a central and common ERP, companies need to think about a common product management, release and delivery toolset. Exception processing which is the norm in smaller companies has a huge impact on time-to-market and cost of goods for larger companies. Using separate processes, separate teams and potentially methodologies to manage the product lifecycle is inherently inefficient and usually more expensive in the longer term.

During the initial adjustment (absorption) period, it is helpful to leave the existing processes in place in order to focus on customer facing issues and cash flow. Minimizing the impact to the schedule and to customers helps mitigate the risk of ‘fouling up the system’. When is the right time to streamline, we believe a company must always be looking at ways to improve process and harmonize business rules, particularly ‘after the dust settles’ but before institutionalism becomes a barrier to success.

This is where common infrastructure can be the catalyst for change (adoption and streamlining), creating a common change point or a common enemy if you like. In the absence of a common release and delivery mechanism, manual exceptions will always prevail. Infrastructure provides the form and flow which defines the process as much as the divergent groups involved in the process. As companies are continually challenged to competitively develop and release products in the global marketplace, companies must look at all aspects of the product lifecycle, as more software is delivered electronically there are greater returns to updating and streamlining the release process from a physical manufacturing/logistics viewpoint to a digital product management, release and delivery infrastructure. The challenge is not only in deploying the infrastructure but also industry best practices while preserving those essential business rules and innate company processes which define the company.

Written by roger242

October 2, 2008 at 13:33 pm


Get every new post delivered to your Inbox.