Rod Collins's Blog, page 9

Don’t Cut the DAM Check Yet! Content and Metadata Analysis are Fundamental Requirements Before Selecting a DAM

All I Want for Christmas is...Customer Service

A Day in the Life of a Paperless NHS

Real Business Is About People

Accountable Care is Accountable Care, Not Just Accountable (Medi)Care

3 Ways the New Digital Road Map Could Land Your Organisation in Special Measures

Good Software Still Takes 10 Years. Get Used to It

by Robert Moss

 

Just over fourteen years ago, Joel Spolsky published a wonderful essay called “Good Software Takes Ten Years. Get Used To It.”  The key point is captured succinctly in the title, but let’s elaborate on it just a bit.

Out of the gate, even if you launch a commercial application successfully and gain market share (or, build and launch a new internally-built corporate application and get the internal users to actually use it), it takes a lot of time to make it great. Almost a full decade, in fact. There are missing features to add, performance issues to resolve, and lots of bugs to shake out. Over the course of the first 5 to 8 years, you get great feedback from the people using your software day in and day out, plus good ideas you can lift from competitors, and the ability to integrate your product with other systems and build in new 3rd party components. (Google Maps, anyone?)

On the flipside, though, after 10 years, as Spolsky puts it, “nobody can think of a single feature that they really need.” Thus you get bells and whistles like the Microsoft Word Paperclip (remember that?) and unnecessary upgrades to the user experience that make things look slicker and fancier but don’t actually improve the utility of the product.

But that was back in 2001. This is the era of agile development, continuous deployment, failing fast, and all that. Kids in their parent’s garages (or in the co-working environment of tech incubators) crank out the code for a new disruptive mobile app in six months, launch it to the world, and sweep up billion dollar valuations because their user counts are soaring and they’re going to figure out how to monetize them any day now. Right?

Spolsky’s rule of thumb, I am afraid, is as valid now as it was when he first wrote it. Oracle’s database took 10 years to get good, Lotus Notes took 10 years to get good, and so will the next new shiny thing. Building software on the web and on mobile devices and slurping down a lot of lattes and energy drinks won’t change that.

But what about Facebook and it’s explosive growth? Did it really take 10 years to get good? Let’s take a look.

Facebook was launched to Harvard students in February 2004 and opened up to other campuses rapidly after that. By the end of 2004 it had its millionth registered user, which is a remarkable thing to accomplish in less than a year, though it admittedly was free and took just seconds to sign up. In September 2005 the platform, originally limited only to college students, was opened up to high schoolers. The support for uploading photos was added the next month—October 2005, over a year and half after launch. The ability to tag friends followed in December, the news feed (the algorithmically generated summary of your friends’ posts) in September 2006, the same month user accounts were opened up to anyone older than 13.

More features followed fast and furious over the next few years, like the ability for developers to create apps within Facebook (May 2007) and the ability to tag friends in status updates and comments (Sept 2009.) Perhaps the most important feature for Facebook’s long-term success arrived in August 2011: the Facebook App for Android and iOS. That was some seven and a half years in.

More recent features, though, have seemed more and more grasping. 2013, Facebook’s 10th year, brought us graph search, emoticons to express emotions in your posts, trending topics—all those widgets that I think of as “the junk over in the far right column that I never look at.” Currently, everyone is all abuzz over the much anticipated “dislike” button, which, in all likelihood, will not actually be a dislike button. 

Earlier this year, Nilary Patel of the Verge made the perceptive argument that Facebook has become the new AOL. The firm logic of the 10-year rule dictates that they would need to: after all, they’ve already built all the features into the original Facebook application that they needed to become the dominant social media platform. If you aren’t on Facebook now, what could they possibly add that would draw you in? So, the ruthless logic of business dictates they must look somewhere else and try to be something else. They’ve finished the product.

OK, but what about Twitter—that got really good really fast, right? On March 21, 2006, Jack Dorsey posted, “just setting up my twttr”, the first tweet, and the service was opened to the public on July 15, 2006—just over nine years ago. Twitter fought hard to resist adding features just for the sake of adding them—even if users were loudly demanding them—and focus just on those that were essential to its success. And still it took a long time.

The hashtag debuted in August 2007. Promoted tweets showed up in April 2010—an important feature for advertisers but also for Twitter’s business model. One of the key features they worked on during the early years, of course, was for the system to be stable and not crash. (Do you miss the fail whale?)  As had been the case at Facebook, just keeping the servers up occupied much of the engineers’ energy.

Twitter went mobile in 2010—four years in—and it did so not by building but acquiring Atebits, which had developed the iPhone app Tweetie. The fall of that year brought the ability to view pictures and videos inside of the Twitter client (instead of jumping via a link to a web site hosting the content)  December 2011 saw the arrival of the “Fly” design to bring a consistent experience across web and mobile.

And now, as Twitter begins its 10th year, it’s worth asking whether it’s entering its talking paperclip phase, where “nobody can think of a single feature that they really need.” The recent reinstatement of , was attributed to the company’s need to accelerate “the pace of product improvements.” But what if the reason Twitter isn’t adding new users at the pace it once did is not because it needs new features but because it has pretty much added all the ones it really needs?

But I’m not so much interested in the 10 year rule because of its implications for those managing mature applications but rather its lessons for those just setting out to create new ones. It’s a warning against the terribly unrealistic expectations on the part of software developers, end users, and—most importantly—the business and technology leaders who make decisions about ambitious new development projects. The crucial business mistakes Spolsky warned against in 2001—Get Big Fast syndrome, overhyping early releases, belief in “Internet time”—are still valid today. Most dangerous, in my view, is the misguided notion that if we just organize projects correctly, staff them with good people, and motivate them correctly we can somehow suspend the fact that making great software simply takes a lot of time and effort. It’s hard work.

I’ve seen that dynamic recently in a team I’ve been working with who are in the closing weeks of a grueling 18-month project. The mission was basically to take a bunch of outdated internal corporate applications and replace them with a slick new web-based front end that integrates with a complex array of older back office systems. They’re dismayed by the bugs and quality issues and “missed requirements” they’re shaking out as they try to take the initial version live and end users are getting into the system to do real work for the first time. Agile stories and collaborative scrumming and late-night coding sessions didn’t prevent those challenges, and they’re left wondering what they did wrong. (The answer: nothing. This is just how it works.)

I’ve seen it in the continuous agitation within the engineering teams at commercial software companies who want to retire a “legacy” platform that’s six or seven years old and rebuild the whole thing from scratch. “We can make it better, stronger, faster.” “How long will you need?” “18 months.” (It always seems to be 18 months. I think that’s because developers really think they can do just about anything in a year, and they throw in a little extra buffer just in case.)

It’s understandable to want chunk all that “technical debt” and start from scratch: our new systems need to be web-based, service-oriented, accessible outside corporate firewalls, and work well on mobile devices, either with a native app client or via responsive design. That’s a lot of stuff that old form-based client-server applications and even older web applications simply can’t do.

But the really hard part is all of the application-specific functions, the business logic, the long, slogging trial and error of figuring out what works for users and what doesn’t. There are plenty of wise things you can do to get good results more quickly, like using commercial software instead of trying to build everything from scratch, and using open source and 3rd party libraries that have a community of developers shaking out the kinks. (It’s really hard to add those essential features you need when you are fixing bugs and refactoring code.) Often it even makes sense to just wrap the old mainframe or put a new front-end on old client server code, as ugly and convoluted as that old code might be.

Sometimes we do need to just throw it away and start over from scratch. But that’s not a decision to enter into lightly, and we should do so with eyes wide open. If you’re doing anything of significant scale, it’s not a 12 month effort or even an 18 month one. Sure, you can get something launched and in use in production, but that’s just the start of the game, not the finish. Good software takes 10 years. And we still need to get used to it.

 

 

Robert Moss @RobertFMoss is a Partner and the leader of the Technology Platform practice at Optimity Advisors. 

Good Software Still Takes 10 Years. Get Used to It

The 3 E’s for Building Support for Critical Projects in Difficult Circumstances

by Gretchen Nadasky

 

Stakeholder investment is the driving force of any successful enterprise undertaking. One of the most important indicators that a corporate project will be initiated is Executive Sponsorship. Taking time to secure a mandate is an excellent investment because it establishes commitment and sets the stage for resource allocation.  Similarly, support from a broad range of stakeholders is a good predictor that a project will be successfully executed.  Unfortunately, many project managers wait until an initiative’s “Change Management” phase to address stakeholders. Rather than wait, it is better to assess the circumstances in which the project arises and build support as early as possible.

Observing that many projects are sabotaged by lack of buy-in before they even get off the ground, we developed The E3 Methodology to build momentum at the very early stages of initiation. The E3 Methodology is predicated on identifying the scenario surrounding the project, choosing an approach to mitigate potential resistance, applying tactics for success and taking decisive actions that will empower stakeholders and build broad cooperation. Interpreting a situation and choosing the right approach are key to gaining traction for an initiative very early in the planning stages—before it is socialized and established. 

Identify the Current Scenario

Corporate projects can come to fruition under a variety of circumstances.  When a plan of action comes from the top down, adoption is likely—people feel they have no choice!  However, when an objective or initiative comes from an individual or group it is more likely to hit resistance.  We have defined three common scenarios illustrating the range of circumstances in which projects may emerge: The Pain Principle Scenario, The Barn Door Scenario and the Elements of Fire Scenario.

The Pain Principle Scenario:  In this situation there is general recognition of a problem, but there is no sponsorship for a solution and the subject is avoided.  Some examples of The Pain Principle Scenario include:  a change in the regulatory or litigation environment that increases risk, employee frustration about a process that causes inefficiency, or the emergence of a competing product that is beginning to gain market share.  If an individual steps up to address the issue on their own they will need to adopt an engagement strategy to build awareness and recruit supporters.

The Barn Door Scenario:  The image evoked in this situation is of a farmer realizing too late that a cow got out of the barn – the problem has occurred and it is necessary for someone to take ownership and address it.  Remediating a disaster that has already happened can be tricky because fingers will be pointed, blame will be assigned and tensions may be high.  In this situation, it is important for the person or team who are addressing the issue to quantify the current state and expected remediation outcomes. Examples of The Barn Door Scenario may be a lawsuit or regulatory fine, a security breach or profit shortfall.

The Elements of Fire Scenario:  Imagine a situation where you can sense impending doom but others see only beautiful nature. It can be very difficult to gain a critical mass of support for a project with the goal of prevention. There may be only one person or group uniquely positioned with the facts and perspective to see the significance of the issue, and it is their job to communicate and convince stakeholders of its importance. The Elements of Fire Scenario is sometimes present when there are complex financial, regulatory or technological issues that require specialized knowledge to solve. The facts of the situation must be approached with enthusiasm instead of doom to garner support of an otherwise ambivalent group.

Choose an Approach and Take Decisive Action

Each scenario addressed in the E3 Methodology should be approached differently. The Pain Principle scenario may be addressed by engaging stakeholders, the Barn Door scenario depends on setting expectations and the Elements of Fire situation is most effectively attacked with enthusiasm.  In addition, a project may emerge in a combination of these circumstances and would then be addressed with multiple approaches.  It is crucial to understand the environment so that the approach matches the situation and informs the tactics employed to gain support. Once the scenario has been defined we suggest choosing the approach that will deliver optimum results.

The Engagement approach addresses the lethargy that is associated with the Pain Principle Scenario. Unlike the Barn Door scenario, there may not be a high-level of urgency felt by stakeholders, but there is a recognition that a problem exists that isn’t present in the Elements of Fire Scenario. Increasing engagement requires communication and cooperation building. Start by studying and understanding the key values of the organization or the group and whose participation is required. Next, introduce or connect those values with the initiative. To gain broad engagement, the message must stay positive and focus on the future state gains of the project. As soon as possible, share small wins to increase a sense of ownership of achievement that will increase participation and power the project forward. Engagement happens when people feel they have a personal stake in outcomes.

Setting and managing expectations is crucial when a problem has already occurred and must be remediated, as in the Barn Door Scenario.  In this case, there is acknowledgement of the problem and urgency is high, but the pressure to succeed can discourage direct participation. The project owner may find herself carrying most of the responsibility. To manage expectations, first identify metrics that will illustrate progress and can be accurately measured.  Keep stakeholders informed by scheduling and presenting these measurable deliverables. Communicate both results and the efforts required to achieve short-term and long-term goals. Setting expectations with quantifiable metrics and milestones at the outset helps define realistic goals and keeps players focused in a volatile situation.

The most difficult and sometimes frustrating scenario for a potential project is The Elements of Fire situation. In today’s world of specialized skills and highly trained knowledge workers, there are many instances where only a handful of people are aware of an emerging situation that could have devastating widespread consequences in the future. Those who can identify a potential future problem must be very passionate and persistent to gain the help and resources for a project where there is no immediate obvious need. Approaching the Elements of Fire with enthusiasm means crafting a message that highlights the positive outcomes rather than fear or threats. The trick to this approach is clearly articulating the problem repeatedly until some people can see it themselves, starting with supporters who may have a stake in averting the probable crisis.

Building support for a project is strategic demanding and takes time, effort and thought but is well worth the investment. Without support, projects can meander, languish or fail completely. Use the E3 Methodology to identify the existing circumstance, choose the correct approach and implement the tactics that will engage stakeholders, set their expectations and build enthusiasm for the initiative. It is never too early to bring more people to the table who will help or at least not resist the change that is inevitably required for any project’s success. 

E3 Methodology in Brief

 

 

Gretchen Nadasky is a Manager at Optimity Advisors.  She advises clients on initiating, executing and sustaining projects in Information and Knowledge Management and has operationalized the E3 Methodology to achieve success.

The 3 E’s for Building Support for Critical Projects in Difficult Circumstances