<!-- Content Here -->

Drupal Panels Tutorial

Readers of the Drupal for Publishers know that Drupal lacks a native system for associating different page layouts for different sections or pages on a site. Sub-layouts are typically implemented with conditional logic in the template code (page.tpl.php). The Drupal Panels module puts this control in the administrative interface and is becoming widely used within the Drupal community. To learn more, check out GotDrupal's excellent video tutorial on Drupal Panels. As you can see from the video, the Panels user interface is quite powerful but is also very complicated because you have to create these rules to determine under what conditions a layout should display. You still probably want a developer or well trained administrator to do the work on a staging environment and then migrate the configurations to the production environment.

Art of Community Now Available

Jono Bacon's new book The Art of Community: Building the New Age of Participation (Theory in Practice)

is now available. I first heard about this book in January and I have tracked the progress and discussion on and off since then. As you would expect from a book about community, the development of The Art of Community was a very open process. I must say that I was a little underwhelmed by the activity around the book given the interest in the topic. Number 1 on the list of top 10 commenters had 29 comments. Number 10 had 7. Maybe most of the discussion happened over Twitter where Jono has over 2,400 followers.

I have no doubt that the book will sell well. Doesn't everyone want to start a community? I just ordered my copy and will post a review here when I get through it. The incumbent for my favorite book in this category is The Success of Open Source

by Steven Weber. Clay Shirky's Here Comes Everybody: The Power of Organizing Without Organizations

is also quite good. Both of these books effectively describe the community phenomenon. What may set The Art of Community apart is a set of instructions for creating your own successful community (Jono draws from his experience with Ubuntu and KDE). But if the techniques work so well, why hasn't the community around the book thrived? Did Jono (who also works as community manager for Ubuntu and is a musician) not have adequate time to write the book implement his techniques?

What the Customer Really Needed

This great cartoon showing how a product is understood and described by different stakeholders is definitely going in my toolbox for explaining project disfunction. My explanation will be that you can't start to achieve a common understanding of something until get visual. If everyone got together and drew a picture of the solution and then regularly checked in as it was incrementally built, the potential for miscommunication would be nearly zero. Proofs of concept, prototypes, and pilots are useful for communicating more complex functionality — Much better than a lengthy detailed written specification.

Eric Barroca Debunking Commercial Open Source Myths

Nuxeo CEO Éric Barroca has an excellent post that breaks down the hype and decodes the marketing speak around commercial open source software. He doesn't name names but he does call out some of the claims and language of some commercial open source vendors. The general message is this: software vendors should focus on making great products and be clear and direct about what they are selling. There is nothing wrong with selling proprietary software or charging license fees — just be clear about it. Don't call a license fee something else to give the appearance that the software is free. Éric also gives a lot of credit to commercial software vendors that contribute to open source (like Atlassian, Day, and IBM) without making a big deal about it.

The J. Boye Short List

Today J. Boye posted a shortlist of vendors that "you should always consider" when selecting a web CMS. While many will take issue about what products were included or excluded from the list, what surprises me the most is that they published such a list at all. Here is why:

• J. Boye is very closely partnered with CMS Watch, which covers 42 products in its Web Content Management Report. Putting out this list would seem to undercut CMS Watch's flagship product.

• The CMS Watch messaging has always been that there is no "magic quadrant" in CMS and I would tend to agree. J. Boye is the first reputable buy-side analyst to come out with one. The title "Web CMS Shortlist 2009" suggests that they will come out with one every year.

• J. Boye does a lot of CMS selection consulting. This list implies that their selection services will start from these 10 products. I think that undermines the value of their consulting services.

I am sure that the J. Boye website will get a lot of traffic from this post and there will be a lot of angry comments from the vendors and open source projects excluded from the list. Hey, all publicity is good publicity, right? It is very interesting to see what J. Boye considers to be "go to" products and what is a global footprint. But this list will not influence what products I consider during the CMS selections that I facilitate.

Hippo CMS 7's New Content Type Editor

Arjé Cahn posted a short video demonstrating the Hippo CMS 7's new content type editor. The process is all GUI driven and looks very slick. It is difficult to know whether this is as flexible as the old Hippo CMS 6 system of editing layout and xsd files but it certainly appears easier. It is also nice to see that Hippo CMS 7 maintains the ability to control the layout of the entry form. Most CMS products only let you control the widgets used, their order, and, in some cases, what tab they appear on. Hippo gives the developer control over the layout of the whole form.

Dimensions of Success (or Ways to Fail)

While most of my consulting work is in product selection, I think the most interesting and rewarding type of project is evaluating the results of a CMS implementation. The typical scenario is that a client feels like their CMS project didn't yield the expected results and engages Content Here to identify what went wrong and what adjustments should be made. Without this type of analysis, it is typical for a buyer to grumble and suffer with the solution for the next three or four years until they have the money to replace it; then the cycle repeats itself because nothing was learned from the experience.

When evaluating a CMS implementation, I typically look at three dimensions: expectations, product, and project.

1. Expectation rationality. Too many projects are doomed from the start because the expectations were set too high. It is often useful to have a third party assess whether the project was oversold or if it under-delivered.

2. Platform suitability. Choosing the wrong CMS product also puts the project in jeopardy. The platform should support your requirements, feel intuitive to your users, be maintainable by your team, and be supported by a well run company that can be a compatible partner.

3. Project execution. The project to implement the solution should be appropriately scoped and phased to achieve short term results quickly and work toward long term goals. You need to select a competent integration partner (internal or external) that you can trust and collaborate with to make good decisions. Your users need to be well supported with training and coaching.

Failure in any of these areas makes a buyer miserable but some are more correctable than others. Choosing the wrong product is the hardest mistake to undo. Migrations are always hard. Even if you can get the data over, all the work to customize and configure the wrong solution is non-transferable. However, it may be possible to minimize the impact through customizations and work-arounds. Generally, these systems are flexible enough to achieve some level of comfort even if it is not ideal.

Irrational expectations is the easiest problem to correct. For example, if it was unreasonable to expect that everyone in the organization (without training) would autonomously contribute their own content, maybe you need to keep that web coordinator role. Maybe some of the benefits will not be immediately realized after the first release of the solution. It is fairly typical to do a few subsequent maintenance releases to expose new functionality or correct bad design assumptions. Ideally, this should be a living solution that is constantly evolving and improving. You are not going to get everything right the first time.

Even though no implementations are perfect, some projects go better than others. Inexperience is the biggest culprit. You want to work with an integration team that is familiar with the technology (on most platforms, it usually takes 2 to 3 substantial projects to establish best practices and patterns). You also want to work with a team that has done similar scale projects, understands your industry, and can speak your language. It is easy to misinterpret requirements and make bad design assumptions if you don't have a suitable context. Sometimes a rocky implementation with a new vendor is part of a natural learning process and things will improve. Other times, it is a sign that two organizations are incompatible as partners.

If your organization feels disillusioned by a recent CMS implementation, the good news is that most problems can be fixed without having to start over. All that is needed is a solid understanding of what went wrong and a roadmap of corrections. Over time, the solution will probably be able to achieve all of the reasonable expectations that you had for it. Let me know if you need help evaluating your CMS implementation. Content Here can put you on a path to improving it.

Magnolia Conference 2009

Magnolia is hosting its first big user conference this September 10th and 11th in Basel Switzerland. I was going through the program and it looks great. There are two tracks: one for business users and the other for developers. The developer track has a session where David Nüscheler will talk about the new JCR Specification (283). There will also be two people from Texas State University to talk about their work with Magnolia. If you are using or considering Magnolia CMS and can talk someone into sending you to Basel, definitely try to go (register here). You can even get a 30% discount off of the €200 standard price if you use the code "mconf09gottlieb".

Fixed bid implementation work: a marriage made in Vegas

Most of my CMS selection clients are not just looking for software. They are looking for a solution that includes software and also a hefty dose of services to configure, customize, train, and support. Typically, once we have narrowed down to a short list of products, we start looking at systems integrators that can help develop the solution. A well-executed implementation and roll-out of a marginal product usually yields better business results than a train-wreck project to implement best-fit software. You need to work with a services organization (internal or external) that can partner with you to define and develop the solution that achieves your goals.

The other day, I was talking with a friend about projects gone bad and he asked me if I ever worked on a big fixed bid project that both client and supplier felt went very well. After considering all the projects that I worked on and the projects that I hear about as an analyst, I had to say no. There was always disappointment and frustration on either or both sides (usually both). But I was able to think of many iterative time and materials relationships that benefited both sides over years of working together. I have now been out of the systems integration business long enough to say, without any personal agenda, that fixed bid systems integration work is a failed enterprise.

The best analogy that I can make is that a fixed bid contract is like marrying someone you met at a craps table on a Las Vegas vacation. I am not saying that all spontaneous Vegas marriages fail, but they definitely have the odds stacked against them. Here is why; during the sales process, both sides get wrapped up in the deal and suppress rational doubts and concerns. They force themselves to believe everything is going to work out. They force decisions and assumptions that turn into a millstone hanging around the neck of the relationship.

The supplier talks himself into believing that he fully understands all the requirements and that every detail about his approach to solving them is accurate. That is simply impossible. No matter how long the pre-sales cycle lasts, it is impossible to fully understand every requirement and bring to light every latent expectation. The client doesn't know what he wants until he sees what he doesn't want. The initial estimate may have even been trimmed down because it "looked too big." The client also assumes he fully understands the requirements and believes he is reasonably flexible about the design details. He trusts that the fixed bid contract ensures the delivery of the solution in his minds eye for the agreed upon price in the stated time frame.

After the deal is consummated, there is a short honeymoon phase where everyone seems to work together productively. This analysis phase goes smoothly because the stressful deadlines are far away and there are no concrete tests for progress. Sometimes a project can go through design without any awareness that it is horribly off course. That realization usually happens during the first development milestones when it is clear that the developer and client had significantly different understandings of the specification (if there even is one). Then things start to degrade very quickly. Both sides are stressed out and start to blame each other. Both parties feel like the other is being unreasonable. The contract that was supposed to protect everyone is turning into a handcuff connected to the most annoying person in the world. Both sides start looking for a way out.

Any successful partnership depends on both parties working collaboratively and creatively to solve problems as they come up. A fixed bid contract prevents this cooperation by making the relationship inflexible. But, you may ask, how much flexibility is realistic when a client has a limited budget and has promised a certain outcome of the project to company leadership and/or the customers? With a fixed bid contract, there is at least clear chain of blame. The business blames the project sponsor. The project sponsor blames the project manager. The project manager blames the consulting company. The consulting company blames the employees. The employees feel miserable and quality suffers. The contract provides unambiguous blaming instructions but it doesn't solve the problem. The project is delayed and other costs will be realized.

A better strategy would be to partner with the supplier to jointly design and develop the optimal solution within those budget, time, and quality constraints. Achieving this kind of solution is an iterative/incremental process. The final solution will gradually materialize as options are explored and learning occurs (see Tracer Bullets). But this kind of cooperation requires a huge amount of trust and, sadly, very few business relationships enjoy much trust at all. Especially given the perceived track record of failed technology projects.

So, how do you achieve this level of trust? It takes time. Just like it helps to date before you get married, you want to start off with some small, low risk projects. Both sides need to believe that if they work at it, the relationship will last a long time and benefit them. There also needs to be transparency and equal rewards. The systems integrator needs to be transparent about their capabilities and experience and they cannot expect a huge windfall over a single project. The systems integrator should consume project resources (budget) as if they were his own. The client should expect to pay for what he gets and not try to trick the supplier into committing to unreasonable results. As Graham Oakes says, if you do not try to the make the relationship a win-win, you will probably wind up being the one who loses.

When you are buying services, you are really buying effort — not a result. A good project team will multiply the effort you purchased with skill and experience to deliver great things (maybe even better than you originally thought you wanted). The problem is, buyers are ill-equipped to gauge skill and experience. They feel more comfortable with the illusion that they are buying tangible results. Services companies that prefer to sell results rather than effort do so by charging a high risk premium (or "value pricing") and having employees that can step up and overwork when the risk gamble is lost. So, the buyer is either overpaying or has hired an overworked team. Neither of theses options sounds particularly appealing.

If you do find yourself forced into asking for a fixed bid contract, do not assume that you can just set your calendar to the planned launch date and wait for the results. Instead, manage the project as actively as possible. Set up lots of intermediate milestones with exit criteria to test that the project is on track. If possible break up the project into multiple small fixed bid phases. For example, have a fixed bid design phase that ends with a prototype or semi-functional core of the application. Make sure that the design considers implementation budget as one of its requirements or constraints. Business owners: don't let your staff get away with throwing the systems integrator under the bus when a project fails. Make them equally accountable for the outcome of the project. If the system integrator is underperforming you should learn of it one quarter of the way into the project; not within weeks of the planned launch date. Even better, don't force your staff to come back with a fixed bid contract. Encourage the assembly of a high performing team of staff and consultants that maximizes the value of your budget.

Social media, where you can stick it

Social Media Publishing Decision Tree

Originally uploaded by sggottlieb

As I mentioned before, I use many different social media services for different purposes. I realized that I have been unconsciously operating an elaborate decision tree of what to post where. On a whim, I tried to map it out and I found the results interesting.

A couple of notes...

• The FriendFeed (ff) icons shows what services are aggregated into FriendFeed.

• I am just starting to use Tumblr again as a sort of personal blog. This exercise helped me realize a use of Tumblr. For a while, I was posting things directly into FriendFeed.

• Flickr contains work and personal items. I use it for personal pictures (mostly public) and also screen captures of software that I review (kept private).

I am wondering if anyone else operates a similar decision tree and how conscious they are of it.