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.

29 November 2009

Highly Agile Product and Project Management for Small Teams

No rocket science here, just a quick entry on a very light way to manage a small and self-contained project team frequently receiving new and modified feature requests while building a new and unproven product.  Goals are minimal process, managing feature creep, and getting the new product into the hands of real customers.

Assume the team is composed of:
  • There are several stakeholders acting as product manager, making feature requests and requiring a high level view of the project.  They are the work creators.
  • One project manager coordinating everything.  The PM vets, routes, value-adds, chases up, and drives completion of work.
  • Handful of technologists and suppliers the project manager is coordinating.  They get work done.
There are two main control documents: product backlog, project plan.

Product Backlog

The first is a product backlog, used to capture all the new ideas and feature requests.  The backlog should be kept in a wiki, google doc, or similar shared location.  For a small team and project the project manager is the chaperone of the backlog, but anyone can put new entries into it.

The backlog is the only way that new feature requests can enter the project.

Backlog entries have these attributes:
  • Who requested
  • When requested
  • Enough detail so everyone roughly knows what is being requested (but no more, not at this point)
As you start adding in backlog requests, put them into a few simple groups:
  • Required to "make the sale", acquire investment, unblock the team, or otherwise business critical in nature ("It's game over if we don't do this right now!")
  • Required as part of the release currently being worked on ("We can't deliver the new release without this.")
  • High want for the next release coming up after the current release ("I really want this in the current release, but I'll settle for the next release coming up."  "All our competition has this feature.")
  • Futures, nice-to-have, everything else ("Cool idea, but we don't absolutely need it right now")
If people other than the PM add new entries, they should throw them into the bottom of the list but can note where they would like the request.  Let the PM move the request into the main backlog as part of their vetting and value add functions.

As backlog items are completed, edit them out of the backlog and into a completed list.  Note when they were completed and by whom.

Tactical Plan

The tactical plan is a simple document written by the PM for the stakeholders that covers:
  • Two lists of tasks:
    • Last week - what got done, who delivered the task, when done
    • What tasks are on-going from last week, who is involved with each, a rough estimate to complete each, reasons for date changes (if any)
  • List of (anticipated) free resources and when available
  • Suggestion of next tasks to put on the tactical plan as taken from the backlog and from other sources
  • List of dates and description for delivery aspirations, commitments and estimates.  Highlight changes from the last meeting
  • List of roadblocks, issues, and risks
  • List of budget/spend requests

Weekly Review

About once per week, the project manager updates a tactical plan for review with the stakeholders.

Before the meeting the PM has done their homework, getting fresh information from the rest of the team and suppliers.  The PM has taken a quick scan through the backlog, looking for fresh, urgent additions and is prepared to make recommendations of which should become new tasks.

The project manager sends out the updated backlog and tactical plan in advance of the meeting.

The stakeholders use the weekly meeting to make changes to the tactical plan.  For efficiency, unless it is an absolute crisis or a critical mistake is being made, the stakeholders agree to not change the tactical plan more frequently than weekly.

The PM and stakeholders also try to avoid creating a long list of partially done tasks, instead allowing tasks to run to completion and not interrupting them with a new task assignment unless the work is really of zero value.

The PM and stakeholders review the recommended promotions from the backlog to the tactical plan and agree on which items to add to the tactical plan in the next 1-2 weeks based on expected free resources.  As new backlog items are selected, makes sure expectations are aligned about what it means to be "done" for each item.

The PM and stakeholders review the roadblocks, issues, and risks to problems solve and make changes to the project and team.

Spend requests are reviewed and approved/denied.

The PM revises the tactical plan and backlog after the meeting is complete and circulates it.

Intentional Exclusions

Other items could be put into the project plan such as QA test coverage and bug lists, code stats, and operational concerns.  However, with a really small team and unproven product, these may not be of much value yet.


Keep things as simple and light as possible when managing a small team working on an unproven product.

Use the backlog to give the stakeholders a voice and to not clutter and thrash the tactical project plan.

Use a one week review cycle to balance flexibility with efficiency.

21 November 2009

Sith Mind Tricks, Episode One - The Management Menace


Sure, all good managers and leaders develop a collection of Jedi mind tricks to create business value and further business objectives.  Unfortunately, bad managers are doing something similar, using their Sith mind tricks to further themselves and their agenda, at a sharp cost to the business and those around them.

What are these anti-patterns of reasonable behavior, good management and so-called leadership?  What are the signs and how can you defeat them?

To start with, you need to understand the Sith.  What motivates them?  Like most of us, they want to further their career to earn more money.  But to do this, the Sith put themselves first, furthering their own progress at the cost of their co-worker's progress.  They don't think about win-win, only win and who cares.  They are short-term thinking capitalists.  They make sure they look good even if that means painting others as looking bad.

Attributes of the Sith

Let's consider general attributes of tricks used by the Sith and how to recognize and defend against them.

Attribute #1 - Siths think in the short term.  Sith mind tricks can be used to great effect in the short run, but they generally result in a win-lose situation overall.

So that gives us the first general general way to defeat them - make sure you're taking the complete picture into account, not just the picture the Sith is trying to frame the conversation in.  Like in martial arts - if you fight the way your opponent fights, you will lose.  Draw them into your way of fighting, your framing of the situation, to win.

Attribute #2 - Siths shrivel in the light of thoughtful logic and complete information.  The powers of robust logic and complete information are anathema to the Sith.  They thrive on speaking rapidly, pulling in whatever facts support their position and silently ignoring or discounting the rest.  They lightly thread one-sided "facts" together with just enough veneer of logic to create the illusion of a solid basis for the uninformed around them.

To defeat this, you just plain have to be better.  Prepare more then them, think about scenarios in advance, critically evaluate viable alternatives, and put forward an airtight set of logic and facts to counter the Sith's view.

Attribute #3 - Siths are multi-faced.  The Sith shows whatever face they need to show to get what they want.  The Sith will suck up to their boss, giving the boss a carefully framed view of a world in which the Sith does no wrong.  They will badger peers to their face and attack them from behind.  They will threaten or just generally annoy subordinates who want to end the interaction with the Sith as fast as possible.

You can't really defeat this one, it's more of a trait that identifies a Sith.  The best you can do is keep the Sith's boss casually informed of the reality of things (not the Sith's fantasy view), encourage your peers not to put up with the guff and fold against the Sith's pressure, and empower your subordinates to escalate as needed to help the business avoid a bad outcome.  And yes, this is a lot of work.

Sith Mind Tricks Featured in Episode 1

And now for the main feature - the Sith mind tricks and how to defeat them.

Trick #1 - Power Relationships.  A Sith takes advantage of their power relationships in the business.  They bypass their peers and go directly to subordinates to secure commitments that support the Sith's agenda.  It's much easier to drive their agenda with someone beneath them in the organization, to use their power to force commitments and decisions from a subordinate.  If they had to do this with a peer or with peers and their boss, the Sith would have to make a case for what they want to do.  Using implicit control over someone's job security and salary is an effective way to assure the person will agree with you.

A Sith is all stick and no carrot.  No carrots except for themselves of course.

If you're peers with a suspected Sith, take note of who the Sith talks to when you are in and out of the office and if they take the chance to go around you directly to your resources.  Know who those people are and make sure they feel comfortable contacting you any time if someone is asking them to do something they feel is a bad idea.  If you're organizationally subordinate to the Sith and they want you to do something you feel is a bad choice, insist that you defer commitment until after you've had time to review it with your boss.

Trick #2 - Win-lose "information" gathering during meetings.  Similar to Trick #1 but in a public forum, a Sith's power increases when they get the answer they want to hear in a public forum.  The Sith will latch on to meeting points that support their agenda and discard or attack ones that don't.  They will badger and intimidate subordinates in a meeting to make the subordinates verbally support or at least not disagree with the Sith's assertions.  If anyone does disagree, the Sith will accuse them of "not being aggressive enough" or "not being a team player" in front of the group to cow them into silence and make sure the person doesn't dare speak against the Sith again.  The Sith of course makes sure that they either publish the meeting results or the "right" view gets put on the minutes.  As a result of this trick, the Sith has public confirmation that they're view is "right" (the "win") but of course the the people in the meeting and the business suffer (the "lose").

A particularly nasty form of this trick is for the Sith to power up trick #1 by wheeling their boss into discussions to really put some weight behind Sith's view of the world.

This trick is also known as "the elephant in the room" (the obvious fallacy that everyone can see but can't be discussed without being attacked by the Sith), "the emperor has no clothes" (execute anyone who points out the emperor isn't wearing clothes), and "repeat the lie until it considered truth" tricks.  It is bullied group-think.

If the Sith gets the power relationships "right" (for the Sith's agenda), they can talk complete bollocks, buck naked, surrounded by elephants.  This is Sith heaven (and everyone else's view of meeting hell).

How to defeat it?  Own the documentation and communication.  Take advantage of the Sith's laziness to write up minutes.  Make sure the issues and objections get documented.  Point out previous objections when an anticipated issue rears up.  Make sure key observations and decisions are at your fingertips when the inevitable blame fest occurs.

Trick #3 - Divide and conquer "information" gathering.  This trick is much like #2, but the Sith relies on trick #1 to corner people individually to extract the answer that they want.  The Sith quickly identifies who is weaker in the team, who doesn't like to argue, who is less informed but also opinionated, and/or who has an axe to grind with their boss and goes after them to get the answer they want.  They will use whatever technique - sucking up, threatening, or badgering - will work to get their answer played back to them by the hapless target.

Once they have that answer, they use it to go after the others on the delivery team saying that person X on the team said that the Sith's answer is The Answer and use it as a way to get The Answer from others on the team.

This trick can be countered by empowering everyone on the team to give the answer they think is right, not one they're being cowed into.  If that doesn't work, insist that certain team members take a "teamwork view" by empowering them to discuss an answer with key (stronger) peers before they respond with an answer to the Sith.

The Sith are good at praying on the weak and indifferent, defeating one person.  They aren't so good when the team works together and is exquisitely aligned.

Trick #4 - Top down scheduling.  Similar to Tricks #1-3, but focused on delivery deadlines.  This trick has the Sith demanding delivery of something from the delivery team by a certain date.  Why the date?  Maybe it's tied to the Sith's bonus, or a commitment they made to their boss or customer without consulting the delivery team.  Regardless, the Sith will assert a delivery date that the delivery team thinks is impossible.  The delivery team does their best to re-estimate, cut corners.  They offer up scope, resource, quality, risk, and technical balance trade-offs to decrease schedule.  The Sith won't accept any change to these (often because they don't want to take the time to understand them), and may even creep scope some because of new requirements that come up during the trade-off analysis.

Over the course of several meetings, the top down date becomes "The Date" and the Sith actually starts accusing the delivery team of "slipping the schedule" and "not making their dates".  The Sith uses Tricks #1-3 to make sure that the team stops pointing out that the delivery date wasn't their date and they never committed to it.

If scheduling reality starts to interfere with scheduling fantasy, the Sith will allude to legal and contractual disputes if the delivery isn't made.  If that doesn't whip the team into shape, the Sith threatens the team with loss of revenue, the business going Titantic, and everyone losing their jobs if the delivery doesn't happen to the Sith's top-down dates.

Why does the Sith do this?  They believe the best way to manage a team is setting aggressive deadlines and threats.  The Sith thinks they can do a better job with top-of-mind scheduling than a knowledgeable team that has spent a lot of time on project planning.  They want control over all project dimensions to better drive their agenda, even though they don't know jack-schlitz about the details.  The Sith thinks they know better, and don't trust the team anyway.  Most likely the Sith is projecting their own problems onto the team.

What happens as a result?  The Sith's ability to get real information drops to zero.  The Sith doesn't want real information anyway, they want their own view of the world spoken through the mouths of the team so they have someone to take the fall when the project fails to deliver "on time".

And how do you defeat this trick?  The counter-trick again is to control the documentation and communication around key observations and decisions during the project.  Keep key historical points at your fingertips.

Of course, the Sith have a counter-counter trick to this.  When the project ends up failing right where the team said it would, they just accuse members of the team of not taking a strong enough position against their view and convincing them that they're right.  It helps to create key information and decision point milestones in the project, carefully document the project reality at milestone (facts, not interpretation), and widely distribute the milestones.  You need to document and communicate the milestone results before the Sith can.  If you communicate the truth enough times, it usually becomes... truth.

What's the triple counter?  You have two choices.

Choice #1, and probably the easier.  Go find a job where you don't have to work with this person ever again, nor a company or bosses that endorse people like this.

Choice #2, much harder.  Put all the information together, create an airtight view of Sith behaviors and decisions during the project, take it to their boss or your mutual boss and go on the attack.  Recommend you take over decision making authority.  Only do this if you're very confident of winning because if you lose the Sith will own you.

The Epilogue

For a few, there is no hope.

Some Sith are just too far gone.  They are a "nasty piece of work" in an otherwise pleasant place to work.  They've pulled the wool over the eyes of their Boss, their peers don't want to be around them, and their employees are driven through fear.  They are ravaging the organization to improve their personal position.  No matter where you work, there will be at least a few around.  Maybe they're customers, maybe co-workers, or maybe just "friends" of friends socially.  You aren't going to change them, and you may not be in a position to drive them out of your circle of interaction.  Just be careful with them, document your critical communications, and make sure you're well prepared every time you interact.

But for most, there is hope.

Not all Sith mind tricksters are beyond redemption.  Maybe they've dabbled with the dark side in a moment of weakness, frustration or stress.  They're in the gray area, and maybe you can help them out by pulling them back into the light.  I know I've been there before, having just done something regrettable to power through a situation, when a Jedi master has come along and kicked me in the backside and back into the light.  If you can do this for someone, it'll feel damn good and you'll have helped your company out as well.  You owe it to them to at least try.

(There are many more Sith Mind Tricks.  Continue learning how to defeat them in Episode 2 - Attack of the Drones.  Coming soon to a blog near you.)

Synology CS407e NAS Cube Station and file move/copy errors

I've been using the Synology Cube Station CS407e as a home NAS for about a year now, and up until a few weeks ago it worked flawlessly. I'm only using it as a network attached media server, not all the other whizzy features it has.

The setup: I have three different machines at various times coping and and moving files around on the box. Trying to be overly clever, I set up a user "write" on the Synology with write permissions so if I had guests in the house using the media server they by default couldn't clobber any files with the default guest access.

Several weeks ago I started having permissions and file move/copy errors. The errors didn't make sense given the relevant context. I tried relaxing permissions by enabling user guest with full read-write permissions. I tried changing login credentials and permissions from the three different clients I used to copy and move files around. Various brick walls. And yes, I was on the latest firmware Synology had available for the CS407e.

I then noticed that I could ssh into the Synology. As I said, I had just been using it as simple NAS. Viola, after logging into it (btw, admin and root logins have the same password) I had access to chown/chgrp via the Unix like busybox interface and tidied up the permissions.

While that solved the problem, it's worth noting that it appears something about the permissions handling on the Synology is broken. The user and permissions setup via the web interface on the box isn't consistent with the errors happening (I had enabled guest with write permissions, still got client side errors) and what I saw at the filesystem level via the command line. So while repairable (ssh interface to busybox), the repair isn't viable for non-techs.

If you're non-technical and not comfortable working at a Unix command line but you still want to use the Synology, I suggest you do not set up other users. Just stick with user guest with the permissions set wide open.

If you've already dug the hole for yourself as described above, I think you can copy everything someplace else, delete all the offending files/directories, re-create a new directory structure with the guest user, and copy everything back.

Lastly, don't let this one problem put you off from considering a Synology for your home NAS.  I've had reliable use of the Synology CS407e for over a year now (as compared to two different Sans Digital MN2Ls previously - yikes, stay away).  It's quiet, reasonably fast, has a top quality management user interface and it Just Works (assuming you don't monkey with non default users!).

10 November 2009

Project Management - the trinity extended

Project management fundamentals teach us that that project management was a trade-off between the trinity of:
  • Schedule
  • Scope (requirements)
  • Resource (people, competency of people, and money)
The three dimensions are in equilibrium and each dimension is proportional (inversely or directly) to the other two.

Formulas like the Ideal Gas Law (PV=nRT) work well to simply communicate the basic relationship between pressure (P), volume (V), and temperature (T).  Very abstractly, project management fundamental values might look like the mathematical formula:

Schedule * Resource = Scope

For example, if Schedule is decreased, then Resource must increase (inversely proportional) and/or Scope must decrease (directly proportional).

Each of three values are only so elastic. To be a practical formula, none of the values can be extremely low (0) or infinite.

Customers/stakeholders may only control one or two of the above three. Not all three. If stakeholders try to control all three and the estimates for all three are reasonably correct, the project will fail.

For example, "scope creep" results when the scope is increased by stakeholders that don't want schedule or resources to increase from your original estimates. The formula indicates that this simply isn't possible and scope creep alone (without compensating by increasing Resource and/or Schedule) will cause project failure.  Note that increasing Resource can also be delivered as improved Resources (e.g., same headcount, higher quality but more expensive staff).

There are three other important dimensions. They are derivative from the above three, but important enough to warrant their own explicit treatment. They are:
  • Quality
  • Risk
  • Technical "Balance"
Expanding the formula, it now looks like this:

Schedule * Resource * Risk * Technical Balance = Scope * Quality

(Note: I use "Technical Balance" rather than "Technical Debt" as I believe in at least some areas you can "future proof" or "over architect" to create a positive/credit balance that may or may not create yield at a later time.  This is akin to the agile tenant of "only build what is required" versus "I *know* we're going to need this in a year, and it's a lot more efficient/cheaper to build it now."  It is also similar to cash sitting in a bank account that you're not investing in a way to maximize yield.  Regardless, a tip-of-the-hat to Ward Cunningham and others on the concept of technical debt, it's brilliant.)

Examples of putting these derivative values into play:
  • Decrease quality to reduce schedule (e.g., launch sooner and let the customer test for us; we only fix what the customers complain about)
  • Create technical debt to reduce resources (e.g., don't bother with code/build tools, don't bother with reducing code duplication or code quality refactorings)
  • Reducing the scope allows us to reduce the risk (e.g., of delivery) - the less to deliver, the lower the risk
The above 6 project management dimensions are about managing participant and customer expectations - making sure the trade-offs you are making in the project are transparent to the customer/stakeholder so they can make better decisions to guide the project.

You could use these 6 items in project status reports or at least during major review points with customers.

Update May 2010

There are emerging approaches in software development coming from the manufacturing world (Toyota) which claim to be tearing down the "time, quality, money - pick two" formula and re-writing the laws of engineering and hence software development.  These practices have been adopted into so-called "lean" practices.

  • The old schedule-scope-resource formula holds, but only if you don't include a time dimension.  Schedule-scope-resource continues to apply in a short period of time, but not in a long period (e.g., due to trading out scope/quality for few resources and tight schedule).  If you are delivering a single shot software, the formula works.  If you are going to live with that software for a long time, evolving and extending it, then you have to include.... time... in the formula.  The time horizon is a business decision.  You educate your business counterparts on technical debt levels, and let them decide.  
  • Good non-tech business leaders responsible for a business that uses tech to power the business must develop an understanding of how to make these tradeoffs, no different than being able to assess balance and P&L sheets.  If they can't do this, they won't be effective leaders of a tech heavy business.  I have yet to work with a business leader that has a time horizon greater than a year, and it's probably closer to a quarter (especially with publicly traded companies: shareholder horizon = board horizon = CEO horizon, and so on).  At least in Internet Gambling, the business doesn't seem to prioritize "built to last" over "get me X right now!!".
  • By including "technical balance" in the above formula, which captures changing technical debt due to scope/quality versus resource and schedule, there is an implicit temporal aspect to the formula.
  • Some technologists prefer to root cause all defects, maximize learning as the business progresses, and keep a very firm, low-debt foundation under them.  However, the reality is that many early stage businesses have to make trade-offs every day between enabling future scalability versus doing whatever it takes that week to get a sale made or acquire a few more customers.  The alternative is the business runs out of money and its game over for everyone.
  • Unless business/board leaders are extremely confident of the business proposition, they are not going to invest heavily in future-proofing the business.  This comes down to the business leaders making the right guesses and being in the right place at the right time (note here the debate between user centered design versus good/lucky business leadership - either is valid in the right circumstances, but bring both together and wow).  Great business leaders being in the right place at the right time is a fairly unique combination.
The formula could have a stronger time basis added to it.  You can't (e.g.) inject money into the formula and instantly increase quality and scope.  It generally takes time for a change in one variable to ripple out to adjusting the other variables.  The same applies by gradually downsizing the team - things don't necessarily start failing immediately.  This is an inertia, latency, or lead time effect.  However, you can minimize the time required to (e.g.) inject new talent onto a team by prioritizing as a requirement the ongoing creation and maintenance of tools, processes and techniques that facilitate insertion/deletion of talent onto a team.

The time basis could also be included from the perspective of the time-value of the scope being delivered.  From a competitive viewpoint, it's likely that having the output right now is of highest value, with scope value decreasing as schedule increases.  This is no different than building a new building - once the decision to build is made, every day the building isn't earning money is lost revenue.  The faster you try to build it, the higher the costs - there is a cost/revenue sweet spot here, but difficult to identify in advance.

Another huge variation is that not all resources are created equal.  Some resources can even create a net productivity loss.  Similarly, as resources mature in a team and learn the codebase/technologies, their efficiency increases.  Therefore resource effectiveness becomes it's own formula that replaces the simpler "resources" in the above main formula.

The formula also doesn't fully capture project "success".  Success comes from successful project execution (formula captures this well enough), but not whether the resultant delivery is successful (e.g, with a customer, in a market, creating positive revenue).  A successful delivery is half or less of the battle.  Creating a product valued by customers resulting in healthy and sustainable net profits is really the battle to be won.

03 November 2009

Portal/CMS selection, some alternative criteria

When selecting a portal/CMS, there are business standard ways to select one:
  • Formal RFI, RFP processes
  • Formal reports from the likes of Butler and Garter
  • Mesh requirements to features
  • Cost
  • Installation consultancy, on-going support provisions
  • Top level Company/IT strategy considerations:
    • In-house versus outsource
    • Open-source vs commercial vs hybrid
    • Technology stack (production support) and language (development)
What is one key flaw with the above list?

You don't actually know if the solution will *work for you*.

The above approach is primarily business oriented and only superficially technology oriented. It is sales and marketing information used by non-technical decision makers. It is information contrived to make a sale. I really believe this is one key reason why so many IT projects fail. Products such as CMS software is selected with only light technology considerations.

And when I write "work", it's more than just the pure technology itself. It's also about integration into your existing environment, IT team adoption, bugs specific to your use of the product, and fit for purpose with respect to your requirements. It's about de-risking the technical side in parallel with the business side.

Don't get me wrong. The above list is important. It primarily provides information to help you sell the proposal with non-technical bosses, stakeholders, and downstream customers. It helps you learn about the partner and your requirements. But if you want to enable a successful project, you should be de-risking deeper technical aspects as well.

It's also important to maintain a commercial view, for example:
  • TTM (Time To Market) requirements
  • Off-paper requirements (e.g., common shareholders between your and the other business; individual relationships)
  • Forecasted revenue benefit to project (i.e., how much can you afford to vet)
Given all this, there is a lighter (higher risk, less work) and heavier (lower risk, more work) investment approaches to software selection.

Light weight investments that can be done relatively quickly (in a week or so) and at lower cost:
  • Check in with colleagues that have been involved with portal/CMS creation, selection, and deployment. Similarly, if you can, determine what your competition is using.
  • Research forums. This is particularly useful for open source or mixed open/commercial source solutions. Look for use of the product that mirrors your intended use - what issues are people reporting? How do the issues change over time?
  • If available, review product case studies. Do the case studies reflect your intended use of the application? For example with portal/CMS, are you trying to build a b2c customer facing website and the case studies are all about ECMs (Enterprise (Intranet) Content Management)?
  • Where is the company based? What is their primary language and how does that compare to the project's primary language? Cross-cultural issues to consider?
  • Use google to look for your proposed CMS - how many pages come up?
  • Go to a recruitment/jobs site like jobserve - can you hire developers and systems administrators that have experience with the CMS?
  • Use google to look for consultancies - on-shore, offshore, outsource - that specialize in the software you're considering
  • Similarly, talk to recruitment agency contacts and ask them what CMS experience they have on CVs and job placements they're working on
  • Perform a more detailed analysis of the system architecture and compare to your own competencies
Let's consider a practical example of the lightweight approach. We are considering two possible portal/CMS/website technologies, Day Communique CQ5 and Alfresco. From a non-technical perspective, we're favoring CQ5.

Checking in with colleagues and in the industry:
  • Most sites have a hand made portal and CMS for their core customer system. This isn't surprising for igaming as most sites are transactional/functional (not content) oriented.
  • Some PHP portal/CMSs are in use. Again, not surprising as PHP was and continues to be the techies choice of underpinning CMS language.
Forums: TBD

Case Studies:
(Aside: note how Alfresco uses "case studies" in the URL and Day does not. I'm might think that Alfresco has people involved that understand SEO and Day does not. Or it could be a language thing.)

Location and Language:
  • Alfresco is UK/English
  • Day is Swiss/German
Google basic search results:
  • "CMS Communique" yields 323,000
  • "CMS CQ5" yields 11,800
  • "CMS Alfresco" yields 961,000
(Aside: Day has made search/SEO particularly hard on themselves as they appear to be moving from "Communique" to just "CQ5" and also sometimes including the "Day" company name prefix rather than just a name. Compare that to Alfresco which goes by... Alfresco.)

Jobserve results:
  • Communique or CQ5 yields 2 job postings
  • Alfresco yields 10 job postings
Google results for consultancy: TBD

Google results looking for outsourcing and offshoring:
  • "CMS alfresco outsource" yields 17,600
  • "CMS alfresco offshore" yields 5,130
  • "CMS communique outsource" yields 6,470 (CQ5 is 384)
  • "CMS communique offshore" yields 12,900 (CQ5 is 2,040)
I also had one colleague report pain dealing with Alfresco consultancy and support.

System architecture review: TBD

(NB: the TBDs here are due to a time limited review and some prior knowledge of both systems.)

I'll let you draw your own conclusion for the lightweight approach.

Heavier cost and lower risk approach is to do two or more Proof of Concepts (POCs). Create an end to end working system that demonstrates some difficult (high risk) functionality. Determine if the system actually works to the hardest bits of your unique requirements. This can be done independently (cheaper, higher risk) or in collaboration with a vendor or consultancy (more expensive, lower risk).

A practical example of the heavier approach? As you might guess, it's TBD!

In conclusion, you'll have some variable amount of time to evaluate portal/CMS choices. Be very wary of a selection driven only by business and not technical reasons. While it might be a commercial reality that you're forced to not technically qualify a choice, you can now at least quantify what should be done and some consequences if you don't do it.

02 November 2009

Software Escrow Services

Had quite a discussion with NCC the other day about software escrows. The net result was that software escrows might as well be a dinosaur with respect to Internet gaming.

Often in a contract you might require a vendor to escrow their software in case the vendor suddenly disappears. On the surface this seems sensible, but lets take a closer look.

Reasons to not use an escrow service:
  • How does the customer verify that the auditing firm has the correct version of software?
  • How frequently does the vendor update the auditor with new software? As frequently as the software is updated in the production environment?
  • A lot of software for web based systems is interpretive (ASP, Java, PHP). You have working source code on your production systems already.
  • Also the working environment you have... works. You have no guarantee that whatever is with the escrow service actually works.
  • Say the escrow service takes in regular snapshots of the vendors source base. What about all the build, configuration, and deployment tools required to create a working production system? What about related documentation?
  • How many vendors have you worked with in your career that have suddenly disappeared? Even if they did, likely someone will still be around to make a few quid and offer you the source.
  • Escrows are sold via sales FUD, which should generally indicate you don't need them.
  • They cost money that could be better spent on pizza (A LOT of pizza) for the IT team
One possible reason might be that you are dealing with a two-guys-and-a-dog software company and they really could disappear tomorrow. Will a company like that really have the time to play nice with a big-boys escrow service? Unlikely. If the software their supplying isn't interpretive code (e.g., big C++ poker server application) then you ought to think about buying the source and having the vendor build the image on your systems. Or only buy software with interpreted code (Java, PHP). There should be a practical/commercial approach that is much more suitable that an escrow service in this case.

Regardless, if you have an operating system in production, the source likely isn't immediately needed.

And if there was a loss of vendor, followed quickly by a catastrophic systems failure, what good is the source going to do you? It's likely you need the expertise behind the source.

I came up with three reasons why we might work with a company like NCC:
  1. A customer of ours insists the third party elements of our software stack have the source code held by an escrow company
  2. Our statutory auditor advises our board that an escrow service is a really good idea (NB: look for new statutory IT auditor).
  3. A cheap way to acquire source if you thought the vendor was likely to fail (although this sounds more like a Sith mind trick!).
Conclusion: Don't bother with software escrow services.

13 July 2009

Web server stats - OS and Browser Usage

Just a few real life stats from a number of UK and EU targeted sites from the month of June, 2009:
  • Windows (XP+Vista) makes up 96% of users
  • IE 6, 7, 8 make up 87% of users (14%, 55%, 18% respectively)
  • Firefox is 11%, Safari at 1.6%
(Stats approximate - usual web log analysis constraints)

21 June 2009

Game client-server coms - choice of IP port and data encapsulation

It's always fun to get down to the network protocol and packet level. One of the things I find frequently misunderstood is how IP port addressing works with respect to outbound firewalling. This comes up when considering how a gaming application can work within a corporate firewall that is blocking most outbound ports.

First, the basics:
  • IP is the network protocol. Basically, it deals with hooking up a client and server to talk to each other by using a source and destination IP address and ports.
  • http is a data format protocol. It is a description of how data will be sent between client and server, and specifies some "meta" data. Think of "meta" data as the address on the outside of an envelope you put in the mail and the letter in the envelope is the data itself.
  • SSL and TLS are two security protocols. They describe how a client and server can communicate with each other securely.
  • https is the combination of http, SSL/TLS
A high numbered port ("source port", "ephemeral port") is assigned by the IP stack on the client automatically when the connection request is sent by client to server. Intermediate networking components such as a firewall may select a different port (known as PAT or Port Address Translation) but regardless will allow inbound (back to client) traffic on the source port until the connection is closed or times out.

To avoid corporate firewalling blocks, a client gaming app should encapsulate data in https and use port 443 ("destination port") to communicate to the server.

Any service on the server can listen on port 443 or any available port for that matter. In the case of a game server, the application can listen for game client requests on port 443.

Using 443 also has the benefit of disabling most (but not all) stateful protocol inspection by a firewall. To be 100% confident of corporate firewall bypassing, the client-server protocol could be encapsulated in https so that the https (SSL/TLS) setup packet inspects as https. While http (https) is expensive in terms of bloat/performance to send small bits of information back and forth between client and server, it has the advantage of effectively tunneling through proxy and firewall security blocks. By implication, don't bother with port 80.

Note that using port 443 should play nicely with corporate proxy servers as well although you would need to explicitly set this up in the client unless you can find a way to inherit proxy settings automatically from the OS or browser.

Also note that while this approach is straight-forward for a downloadable rich game client, it can be harder in Flash game client.

A few documents you might find useful:

24 May 2009

Portal Versus Content Management Systems (CMS) Versus Web Pages


There is a lot of difference of opinion on what a portal is.  This is down to several common, conflicting definitions of portals, thinking that portals and CMSs are the same thing, and many different ways to actually build a web page.

Closely related technology and terms will also be covered, along with some practical best practice recommendations.


In the mid to late 90s, the first phase of web applications were the same as websites.    Portal and CMS concerns blended together.  Website developers recognized the need for a control panel to control the customer facing part of their site, to which they added some content controls.  They controlled the whole delivery stack.

By the late 90s to maybe 2004, a number of CMSs became available.  This was the second phase of website construction.  You “had to have” a CMS.  These CMSs blended together portal and CMS concerns.  The CMS was the website – pages, content on pages, how pages linked together.  Great for content sites, but building a transactional, functionality oriented site was painful and expensive as the CMS had to be extended.

Also during this time some very clever people working on Java standards recognized the difference between portal, portlet, and content services and wrote JSR-168 (later 286) and 170.  They got it, but practice was well behind theory.

Starting as early as 2001, but really more by 2005, AJAX and web services were catching hold.  The idea that you didn’t need to control the whole delivery stack became clearer.  The first mash-ups started to appear – pulling in services from one website (service) into another.

Also at the same time, an older concept finally caught, which was the separation of content and business logic.  This was the old MVC (Model-View-Controller) approach, but people finally rallied around it.
This leads to the third phase, which we’ve been in for maybe 3-4 years now.  People began to realize that a website is really a container that can draw services from anywhere.  They also refined the MVC approach to separate content-with-format into content and presentation of that content.  They also took a more granular view of web page construction, effectively creating an MVC for each component on a page rather than treating whole pages at a time.

As a result, a portal became a "container of containers" that pulls in and visually organizes content and functionality from wherever it can, but isn’t otherwise primarily concerned with content itself.

Today (mid 2009)

Which takes us to today.  In a nutshell, if a site is very content oriented (not function/transaction oriented) and the content is self-contained, one of those big CMSs may still be appropriate. 

If a site is quite mixed (content, functionality) and has small volumes, little revenue, you still just hack everything together like you would in the 90s.  Same for those that haven’t made the jump in understanding the differences of concern between portal and CMS, don’t require multi-service integration, or “control everything”. 

For everyone else, content and portal are being treated as separate areas of concern.

Making things more complex is that all the terminology and definitions are evolving, quite variable and/or misunderstood.


A portal is not a CMS!

A portal unifies together one or more service providers into a unified user interface for an information and service consumer.

Examples of service providers and services used by a portal:

  • Customer handling system – create and manage customers
  • Payment system – debit and credit a customer’s credit card
  • Mash-up classics: flickr photos, google maps and news, youtube video
  • Content Management System (CMS) – manage content
The service providers may be based on different technology stacks.  In some fashion (there are various) they need to export (make visible) the services they offer.

A service provider, particularly a legacy system or one that is difficult to change, may not use web services or may not be able to easily change the web services it has.  In this case it is common to create some middleware to form a bridge between the legacy system and portal.  The middleware speaks “legacy interface” on one side, and provides a set of modern web services on the other.

The service providers do not need to know about or interact with each other to provide their services (not coupled).  The connection between the portal and the service providers is flexible (loosely coupled).

Assuming the service provider interface remains the same or is backwards compatible, it may evolve independently of the portal consuming that service and other service providers in use by the portal.

Web based solutions are typically a website as displayed in a browser or a rich Internet client (e.g., an MMRPG client).  A rich client stands alone, a website requires a browser.

Choice of portal means choice of technology.  The most common models are the "P" family (PHP, Perl, Python that sit on the front of a LAMP stack), ASP/.Net, and Java.  There are others growing in popularity like Ruby.  Choice of technology will drive the portlet approach which is covered next.


Portlets are also called fragments, widgets, blocks, or CMSlets.

A portlet is used to encapsulate a service provider’s service or combination of provider services.

A portlet provides a uniform interface used by web page authors to construct web pages.

It is possible that a service provider might provide a portlet directly rather than a service that the portal encapsulates as a portlet.  This is dangerous because it creates a greater degree of coupling between website construction and an underlying service.  Conversely, it might be faster as web service and portlet are collapsed into one (less code, simpler, less fragile).  Note that this is only possible if the service provider uses roughly the same technology as the portal.

Aside: A rich client may have an equivalent to a portlet, a way to encapsulate a service or combined set of services in a uniform way for the client.

Content Management System (CMS)

Sometimes a CMS is a portal!  But it shouldn’t be.

A CMS is an optional services that a portal can draw on to manage content.

A portal encapsulates CMS services into portlets so a website author can dynamically mange website content.

A CMS should contain all site content – both text and images.

A CMS supports localization of its content.

A CMS will have a backoffice interface to manage the content.  A content administrator can preview content updates in a pre-production (staging) environment prior to live publication.  Content is under version control - who/when is recorded when content is created and changed.  Other typical backoffice functions are present: workflow, audit trail, role based access controls, reports.

A portal may pull text from the CMS and mix it with transactional functionality from a service to create a customer solution.  For example a portal might have a portlet for a registration page that pulls all the field prompts from the CMS but creates the customer in the customer management system.

Historically CMSs owned both blocks of content on a webpage and the webpage itself.  They mixed together portal and CMS concerns.  This is bad for transactional sites as it makes it more expensive to evolve website functionality.

CMSs have many other feature considerations, this is only a high level view of them when positioned in the delivery stack as a service and relevant to portal integration.

A few best practices when working with CMSs:

  • Content seen by a customer is never written into a web page.  The web page author requests content from the CMS.  The author knows the context on the webpage and brings in content appropriate for that context.
  • A CMS should never be able to publish Javascript.  Javascript should be considered as application code and flow through a control/QA process before live site publication.  Javascript should be encapsulated in tags, not be present in the web page itself.
  • A CMS should only publish content with a limited and well-defined set of safe HTML tags around the content.
  • Sometimes content and functionality is interdependent.  For example, a new promotions page with some user interaction (e.g., enter a mobile # to access a promotion) needs to go live at the same time as updated (e.g., T&Cs and various links to the new promo page).  To support this, a number of related content changes can be grouped as a change set, and only published all at once when the new functionality is deployed to the production environment.
  • In a shared services environment (one infrastructure and software stack running many different websites), the CMS will require strong RBACs to prevent partners seeing or accessing each other’s content.
  • Only bring in the CMS you need.  When you only need content control over a few areas, its a viable option to leverage simple tools or just roll your own CMS.  This is where many companies make the mistake of bringing in an expensive CMS package and customize it versus just having a couple of web page authors making updates and handing the business a simple backoffice interface to update a few portlet's content.
  • Ideally a CMS contains all service messaging, including error messages.  A service passes along a code for what information to display, the portlet looks up the information in the CMS using the code as a lookup key.

Web Pages

One thing that might feel uncomfortable with the above CMS definition is that the CMS only controls content as displayed in portlets rather than whole web pages.  It's ok, this should feel uncomfortable to some of you.  If you must enable end users to quickly and non-technically create and deploy new web pages to your site, your only choice is to look at a more traditional big boys CMS and hand your soul (and wallet) to the consultants to tailor the CMS to your business.  It means you're going to have to write a set of customized plug-ins for the CMS in the CMS's terms, usually something proprietary.  You may be able to hybridize your approach as well, and I'll cover that below.

However, if the view of CMS as a supplier of CMS oriented components/portlets and not necessarily whole pages is making sense to you so far, let's move into what that means for constructing web pages.

Web pages are requested by a browser.  The browser may pass in a number of parameters when requesting a web page to achieve an affect such as moving through a workflow.  Web page requests are received by the server.  The server identifies the correct page and processes it.  The pages are then handed to a customer’s browser, and processed further by the browser.

The server processes the web page by substituting custom tags with HTML and Javascript.  The custom tag methodology is provided by a custom tag framework as specified by the portal technology choices.

Web pages executing within a client contain a well defined and consistent interface to access dynamic functionality on the server.

Web pages are written by web page authors (aka designers) who specialize in HTML and CSS.  Custom tags aren't a big stretch for them but complex Javascript might be (they typically aren't programmers).  The closer these tags look to conventional HTML, the more effective the HTML/CSS web page authors are when using them.

A few best practices when considering web pages:

  • Web pages typically contain Javascript.  A lot of Javascript in more advanced, interactive, dynamic web pages.  The Javascript should be encapsulated in custom tags or portlet and server side substituted into the web page definition using a custom tag interface.  Javascript should not be added to pages directly.
  • Web page authors are most comfortable working with a whole web page inside an HTML editor as stored on a filesystem.  Submitting web pages into a database (that is, web pages pulled from DB, not served from filesystem) is painful.  Reformatting XML data extracts via XSLT is painful.  This is why web pages best live at the filesystem level and not inside of a CMS.
  • Web pages are under version control and must be checked in and out.  
  • New and updated web pages must be tested on a pre-production (test) environment prior to being placed in a production environment.  
  • Web pages should be published to production in a controlled and audited way.  There should be a toolset that supports this activity to make a web page author’s life easier.  You might almost consider this a webpage level CMS, but with a different users and tighter production release style controls.
  • The CSS is a web page concern.  Designers own the specification of what the CSS markup should do.  Portlet and custom tag developers own insertion of the CSS markup itself.  Developers and designers must work together via a "CSS Contract".
  • The portal must force subordinate services to use a well-defined namespace for CSS use.
A Hybrid view of CMS and Web pages

If for whatever reason an expensive enterprise grade CMS with a recognizable brand is a hard requirement for your website, you have two choices:
  • Write custom CMS plug-ins to integrate all the server side functionality you require to build the solution.  Be aware:
    • What you build will most likely be non-portable to other CMSs in the future
    • You've achieved vendor lock-in.  Vendors like this - you may not in the future.
    • You're likely going to have to (re)train a group of developers to write the plug-ins for the CMS.  The big boys CMSs are big and complex and you're going to have to develop a lot of vertical knowledge to make them successful.
    • Be prepared to bring in consultants specializing in the CMS to help your delivery team and operational support team.  Vendors also like this - your CFO won't.
    • Be prepared to closely risk manage the new CMS technology risks (like any new, big, complex technology introduction) across your IT team and into the business
    • The CMS controls the whole website page.  Designers must work with the CMS to create and update whole page designs using a proprietary approach.  Designers will be creating page "templates" which are then throw into a stable of templates that non-technical users access to create new pages on the site.
  • Look at a hybrid view
What is the hybrid view?  Assuming you have the staff and dosh to make this happen, create two parallel delivery tracks.

Track 1 is about delivering a site using the way I've described above, with strong separation of concerns between services and portal, treating the CMS as a service.  The portal owns the web pages, specifies the technologies to be used to construct pages and support client/browser and server interaction.  Assuming you have a team of people that have done this before, risks are low, productivity is good, and the website comes into being rapidly.  Keep Track 1 focused on the core user journeys web pages and lightly stub all other pages.

Track 2 is about deploying the CMS, building up an understanding of it, and seeing what you can do with it while Track 1 is building the website.  To start with, Track 2 should focus on delivering content heavy and frequent content changes pages into the solution.  Track 2 pages should be covering off all those lightly stubbed pages you're creating in Track 1.

You then bring these two tracks together.  Ideally you can get to the point where the Track 2 CMS controls the content heavy, functionality light sections of your website, while the Track 1 website focuses on functionality heavy portions of the site.

To accomplish this, you'll at least have to write CMS plug-ins to functionally provide login, session, logged-in status, and one or more navigation blocks.  This will allow you to maintain the customer's login state as they move between Track 1 and Track 2 pages.

What are the benefits of the hybrid approach?
  • Primarily, it's risk management.  The approach de-risks the use of a new, big, complex technology.
  • Can get a basic up and running quickly, assuming you are building websites in a standardized way, using the separation of concerns as outlined in this blog.
  • You can incrementally shift functionality from Track 1 to Track 2 based on growing depth of knowledge of both approaches.
  • But you don't have to shift everything from Track 1 to Track 2 - you can take a balanced priorities, efficiency, cost view of how to evolve the two tracks.


Portal, CMS, and web pages are not the same thing.  Each has its own concerns.

Portals mix together various types of functionality to enable an end-user facing solution.

CMSs manage content and provide services to the portal to access content.

Web pages are the practical implementation of portal provided functionality.

If you architecturally mix the three together, perhaps to save initial coding time, you are creating extensibility and team scaling limitations for yourself later.  There is potentially nothing wrong with that - just go into it with your eyes open.

01 March 2009

Product versus Operational Management

At least in the world of Internet Gambling, product management tends to have two parts to it: an operational side and a futures side.  I'll call these two roles "Product Manager" and "Product Operator".  As an organization grows these roles will tend to separate as each requires quite a different, and potentially conflicting, mindset.

Product Manager

- Product managers are responsible for the long term aspects of the product. They are more strategic and project oriented than on-going operationally oriented.

  • Understand how investment in product correlates to revenue.
  • May own product (line) P&L, but this really depends on the organizational structure and size of the company and the role of the CEO (who ultimately owns the overall P&L).  If a Product Manager owns the P&L, they're really more a business unit (subordinate CEO) manager.
  • Focused on product futures
  • Domain and product expert, including market and competition.  
    • This typically requires research and analysis, and producing briefs and presentations to keep the rest of the business in alignment with product and market vision.
    • This may include evolving government, regulatory, and licensing structure
    • Support sales and bizdev opportunities to a certain level of product depth, and certainly in the context of a competitive selection (a Product Operations Manager will typically know the current product in a greater depth than the Product Manager)
  • Documents roadmap including setting feature/backlog priorities and asserting timing aspirations.  
    • Requests, aspirations, and priorities should be gathered across the business and customer base.  These are synthesized, traded-off and put together with product strategy and technology requirements.
    • Maintain an evolving roadmap to be constantly prepared to communicate vision, strategy and plans.
    • The roadmap isn't just features over a time period, it's also the key drivers and ideas behind feature priorities and timings.
    • Lots of communications - with bizdev/sales about what's coming up, with marketing on new and updated features
  • Drive consistent use of businesses cases and related process expectations.
    • Create new and improved product business cases
    • Educate product stakeholders what is required to get a new feature, product, or bug fix into the product backlog
    • Must know when to break/bypass the process when a unique and compelling opportunity is presented.
    • Identify how to identify and monitor business case assertions (KPIs)
  • Document requirements and non-technical business logic
    • Set expectations into the business about what is required by a delivery team or supplier for that team to effectively deliver new and improved products
    • Create visual mock-ups and prototypes to help communicate requirements.
    • Champion the user and commercially-sufficient-quality user experience
  • Works with a project, solutions delivery and/or software development manager to deliver new features and functions.  The Product Manager is the domain expert that the technologists consult for feature/function decisions.
  • Customer of delivered product from in-house development or suppliers
    • Guides schedule-scope-resource-quality tradeoffs
    • Understands and monitors technical debt level and makes short/long term technical investment decisions and priorities
    • Verifies results against requirements (directly or using a QA team by proxy)
  • Post delivery, measure business cases against reality. Create enterprise knowledge around what deliveries create revenue and who is driving them.
  • Supplier selection, negotiation, and management, particularly the commercial/legal aspects.
Should product managers have staff or be like programme managers that tend to rely on other's staff and influence to get things done?  My view is that as organization and product complexity/diversity grows, product managers must build out a team support all of the above responsibilities.  Using influence to contend for (often precious) resources increases time-wasting political challenges.  In particular, appropriate staff are:
  • Business analysis.  People that can develop deep domain knowledge, produce market/product competitive analysis, and create specifications.
  • Visual requirements author.  Depending on the capability of your BAs, they may need a semi-technical person to work within Powerpoint, Photoshop, HTML/CSS, Javascript to put together wireframes and non-functional prototypes to communicate requirements.
  • Project/Programme managers.  For larger projects, you need staff to glue together all the moving parts and manage aggregate progress and risks.
Note that Product Management can really overlap with IT, in particular with PMO and QA teams.  It doesn't really matter where the Product Management functions sits, although in an emergent and high growth  area it's probably worthwhile to keep it separated from technology to facilitate overall scaling of the business.  As the competitive advantage of product differentiation that comes through excellent product management decreases, it may make sense to merge it into Marketing or IT as a potential cost savings.

Product Operator

- Product operators are focused on extracting maximum value and efficiency out of the platform as it exists today. They understand the current product better than anyone else -  they're using it every day.  They feed operational inefficiency issues and new feature requests into the product manager.

  • Focused on day-to-day operations of a product
  • Current product experts - they know how the product works, all its quirks and foibles
  • Uses backoffice systems to:
    • Manage live product configuration
    • Produce reports, analyze live data and product performance
    • Solve customer problems
  • Maximizes product revenue within the constraints of an existing product
  • Own a tactical backlog of improvements and fixes that would improve product operational efficiency
Potential Conflict

As organization and product complexity and diversity increases, it's important to separate out operational, execution, and tactical excellence from futures and strategic excellence.  I find time and again these two ways of thinking pop up in all areas during business growth and need to be separated to work well together.