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.

Summary

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.

Sith Mind Tricks, Episode One - The Management Menace

Prologue

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

Synology company home page

CS407e product overview

CS407e technical specifications

Download CS407e firmware upgrades

Synology CS407e NAS Cube Station at amazon.com

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.

Observations:

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

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:

• Communique/CQ5 had eleven case studies, one of which looked like what we need to do
• Alfresco had 24 case studies, not yet reviewed.

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

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.