13 December 2009

Supplier Reviews

The following is a sample agenda for a supplier review.

Objectives for Review
  • Agree a plan with supplier to solve key issues
  • All ownership, processes and contact points well understood and up-to-date
  • Understand where the supplier is going, their strategy and roadmap
Areas to Consider
  • What areas does the business want to see improved; what are the pain points with this supplier?
  • Number of new features delivered (e.g., new products and/or services made available, functional improvements, elements of previous supplier review agenda delivered).  Consider both velocity and acceleration of deliveries.
  • General process improvements (e.g., escalation of issues back into supplier)
  • Review major product/service failures and downtime events – root cause?
  • Review product/service roadmap, both current and from last time.  Assess delivery ability against stated roadmap as a way to evaluate currently presented roadmap
  • Evaluate other customers of the supplier - their situations, requests; how are they driving the suppliers strategy and priority choices?
  • Roadmap of technical/internals
  • Upgrade plans
  • Review who owns what and escalation details; general review of support and ability to escalate
  • Review recent and related project retrospectives - any issues to progress with supplier?
  • Can the supply/delivery chain be optimized? Come into session with a summary of the delivery chain, owners and timing - what can be tuned?
  • Supplier costs summary.  Any invoice issues.
  • Alternatives to supplier
Output of Review

If this is a major review, consider setting up a wiki page that pulls together all the information related to the review, e.g., specification, bug lists, retrospectives, API specs,

Documentation updates, e.g., a supplier support change names and phone numbers

Action items between now and the next review.

05 December 2009

Spectrums of website control - from tech to non-tech

Sometimes it's not clear to a non-technical consumer of a web site what is involved to change content, style, layout, and functionality that make up the website.  In particular you're interested in enabling websites to be built, updated and extended by non-technical staff.  This entry is about explaining the spectrum of possibilities  in change in each of these areas for non-technical users, for example a non-technical website product manager.

Static Content

The static content of the website is all the text and graphics you see on a page.  It is not about functionality (e.g., customer registration), navigating between pages, or other browser-user interactions.  "Static" is a bit of a misnomer in that the text can be changed using the two methods below.  However, it is not about dynamic content that changes on a page without you requesting it to change.

At a basic level, content can be inserted directly into a web page that sits in a file on a filesystem.  To make these types of content changes, one must know at least some basic HTML and maybe CSS.  These types of content changes are typically done by a website "designer", more aptly called an HTML/CSS author.  Many, many websites start out with this approach - it's easy if you know how to do it.  There are no special costs for purchasing, integrating, and/or learning specialized content administration tools.  This could be considered a "technical" activity as it's generally not simple enough for someone without some basic HTML/CSS and related tools training to do.

At a more advanced level, there is some types of forms based interface that allows a non-technical user to make content and image changes on the website.  There are many levels of variation and complexity at this level.  Workflow, publication control, localization flow, version control and security become differentiating features.

Website Design - Style

The design style of a webpage is typically brand and "look and feel" attributes of the page.  At a simple level, this is colors and type/size/modifications of fonts.  The goal is to have a common style and brand feel across all pages of a website.

At a basic level, design may simply not exist, using browser page rendering defaults to style pages.  This is quite common early on in website/page development as you want to focus on other factors and not design.

As the design approach matures, style may initially be embedded directly in a webpage and closely associated with (located with) the content the design is being applied to.

The next level of maturity is to separate style from what is being styled.  One style view, as defined in a globally used CSS definition, is used for all pages in the website.

For all of the above, it is a technical activity with an HTML/CSS author working with files at a filesystem level.

As with static content, the jump is then made to having a forms based interface to change style dynamically.  The syntax of CSS is somewhat hidden away and simplified by the forms and fields a non-technical user interacts with.

Website Design - Layout

Separate from website style is website layout.  Layout is about how the various blocks of information on a webpage are placed on a page.  The goal here is to balance a uniform customer experience across all pages of the website versus contextually unique information and functionality that appears on specific pages.  For example, all pages of a website may have the same top bar, left navigation, and bottom set of links, but then have significant variation of information and functionality in the other parts of the page.

As above, layout can be done by hand by a HTML/CSS author for each page in a website.

As the manual process matures typically driven by a growing number of web pages, some type of organizational framework is implemented so that a uniform layout is used for all web pages.  Developers who implement the framework start working with the HTML/CSS authors to support them when implementing the framework.

The solutions complexity then jumps up significantly to enable a backoffice to manage layout of web pages.  There are basically two varieties of these currently available:

  • Technical staff create a page template where the blocks of content and functionality on the page have a fixed layout.  Non-technical users can create new pages using the template as a base, but can't otherwise change the layout.  This is like working with MS-Powerpoint master templates.  
  • A little more advanced is creating a fixed layout of "containers" of functionality on a web page where subordinate blocks of functionality are contained in a larger "container" block.  Popular blogging software such as Wordpress take this approach.  You can't change the overall layout, but you can pick the type and order of functional blocks within the container.  The blocks require technical work to create, typically developer and designer.  Nicer interfaces allow a drag-and-drop placement of the blocks.
  • The most advanced layout approach is to allow full construction of a page or parts of a page by drag-and-drop from a toolbox of functional blocks.  The blocks may be placed, sized, and configured via a forms based interface by a non-technical user.  The page may have a completely free-form layout, or inherit certain fixed attributes (e.g., to enforce a common header and navigation at the top of all pages of a website).  A non-technical user may define a "template" layout then used by actual website pages, again like a Powerpoint slide master.  This approach may enable non-techs to create and manage pages, but uses very complex technology underneath to support this capability.  Google Sites is an example of this layout approach.

You can see from the above that layout starts technically easy to implement but doesn't enable non-tech users to manage layout.  At the most advanced, there is a lot of complex technology required, but non-tech users can control the layout of web pages.

Note that sites built using the more advanced tools tend to be blocky, linear, and very functional looking.  This is because a good designer isn't working on the layout, only a limited layout software and non-techincal (non-designer) is building the pages.

Website Functionality

We've covered the non-interactive attributes of constructing websites - content, design, and layout.  We've noticed that layout can place functional blocks, and we'll now take a closer look at them.

Functionality must be built by technologists.  As we've seen above, it's possible to enable a non-tech user to drag and drop functionality into a web page layout, but non-tech users can't create new functionality.  You want to register, login, conduct a transaction, or display dynamically updated content on a website?  Technologists will build that.  Yes, there are interesting projects like Yahoo Pipes, but they're more of a toy, very cool, but not fit for small business or little less enterprise level websites.

Given that functionality must be built by technologists, what are the various ways to build that functionality?

At a basic level, a lot of website functionality can be built directly in a web page.  This is a simple and quick way to introduce many classes of new functionality, but is quite limiting when extending and maintaining the functionality.

A much better practice is to reference functional requirements in a page, but implement the functionality completely separately.

In order to support a "page made up component blocks" for example as required by advanced page layout tools for non-technical users, functionality must be constructed in a very specific way that will play nice with the layout and design frameworks in use.

The Spectrum from and end user perspective

With all the hype around what was user generated content and what is social media (user generated content within defined networks of consumers), what are some practical implications of enabling non-technical user outside the business to manage their own pages and content within the business' website?

The first thing to think about is delegation of control.  For example, how much control do you want to pass on from the technology team to internal non-technical users?  One typical consequence when this happens is that site quality drops as the QA process is decreased but the increased flexibility and scale is deemed to be worth it.

The next step of delegation of control is to trusted external partners and suppliers outside the business.  "Trusted" is no doubt a stretch when describing some of them.

The final step of delegation is to pass control to end users.

For all of these steps of delegation, you have to decide what you can "safely" delegate, balancing scale and customer control versus internal governance and quality controls.  And of course your ability to delegate safely is based on how you've implemented the functional blocks you have to work with.

Let's take a look at a specific end user example.  In the beginning of a website/service, everything is controlled by the business - the user journey, what they see on each page, the functions they have available to them and how they are visually organized.  They interact with the site only to submit information and see results.

The next step is user generated content such as a user homepage with simple "about me", a photo, and blog/status functionality in a fixed format.  Then some user interaction functionality is added like forums and chat.

Then one or both of the following happen.

Path #1: As the site evolves and more functionality and content becomes available the customer really wants to control what they see and do.  The site's one-size-fits-all approach is breaking down.  The only thing left to do is to enable the user to create and manage their own experience by selecting functionality and content important to them, organized in a way that makes most sense to them.

Path #2: The website product manager, realizing the site can't be all things to all people, can't be another Facebook, separates out and emphasizes the core business proposition functionality from all the non-core me-too "extraneous" functionality they've worked so hard to create.  They have a Starbucks moment and realize that they need to be where their customer is and not make the customer come to them.  Enter web services into Facebook and the like and exit stand-alone business websites.


Websites are made up of content, style, layout, and functionality.

The technology exists today to empower non-technical users to create and manage websites.  There are limitations to this, and some of the underpinning technology is complex, immature, and proprietary.

Like with most technology areas, the more you want to simplify technology so that technology specialists are not required to operate the technology after implementation, the complexity and cost for the project increases.