-
About
Notes and views on CRM, open business models, and what the Web means for customer relationships. [more]
-
Speaking at:
Telecoms CRM, CEM and User Experience 2008
Travel
Linkblog
Photos
Apple’s way isn’t the only way
Dare Obasanjo made an excellent argument about user experience and the open ecosystem can fail when it doesn’t deliver that. It was particularly painful for me to read and acknowledge. Openness is a virtue but virtue alone doesn’t make a viable business model.
Developers go where the users are. Users go where they can get the best user experience for the right price. Openness of the platform only helps if it improves the user experience, thus attracting more users and reinforcing the virtuous cycle.
He then goes on and compares the Windows Mobile way of installing software versus the iPhone way. Needless to say, Windows gets quite a beating.
As someone who has recently had his WinMo smartphone go nuts to a point it had to be re-flashed, I am not blinds to the faults of the platform. Neither am I turning my head away from the unfulfilled promises of the Linux-based handsets. It’s bad.
Is the Apple model worth following, then? Should Google play their game with Android?
I believe not. Though mobile phones are not PCs (and Windows Mobile fails most when it makes you think differently), they are not iPods either. They fall somewhere in between. So it’s OK if they are married to laptops for the purpose of installing software and/or maintenance - as long as the guy manning the laptop doesn’t have to do much thinking.
It’s the platform’s jobs to make that marriage a success. Everything else can be left to developers. And they will come if that experience makes sense. If Android or any other platform can start making sense, I don’t see why it wouldn’t attract its share of hearts and minds.
Sphere: Related ContentDel.icio.us back in Web 1.0
Delicious.com?
Mis-spelled and “dotted” domain names have become the mandatory feature of Web 2.0 sites. I’d venture to say Del.icio.us was, if not the first one, then certainly in the first wave of companies of this sort.
Delicious.com?
Not only the domain name but also screwed-up user experience has pushed the new release of the social bookmarking site back into Web 1.0 world where its parent, Yahoo, resides.
Let me qualify that: the very first contact I had with the new release was when I chose to sign-in from the del.icio.us Firefox extension. It led to a Yahoo page saying I wasn’t authorized to access that page.
Unauthorized to log in?
I hope that once I get in, I’ll find a reason or two not to churn.
Damn.
Sphere: Related ContentDoc Searls on VRM
Doc Searls explaining VRM to a Telco crowd at Mobile Monday in Netherlands:
Worth watching. CRM 2.0 and VRM aren’t neither synonymous nor adversarial but complementary, and I am glad to see that both camps are finally coming together.
Sphere: Related ContentThe Coolness Factor
Firing up your office laptop, logging into SAP and screaming WOW: no, this doesn’t happen. Enterprise software is boring, and quite frankly I cannot understand where does the whole bunch of Enterprise Irregulars find the temerity to tell Scoble he was wrong to wonder, Why enterprise software isn’t sexy , and say he doesn’t get it. There is nothing to get, folks: enterprise software is boring, boring, boring, 99 percent of the time, and no, it doesn’t have to be; methinks Workday looks pretty cool (judging from the demos), and so does Salesforce.
And you know what? It’s not a coincidence I’ve picked up these two. SaaS is a disruptor in many ways, and one of them is getting rid of the internal IT and all its silly policies, long implementation times, and the inevitable hordes of consultants. It has to appeal to users.
But I digress. Enterprise Software is so horribly soulless and user-unfriendly due to a number of reasons:
- Purchasing decisions are made by paper-pushers. End users are usually not involved as they are “represented” by a somebody who hasn’t been at the frontline for a long time, won’t be using the software, and therefore doesn’t really know what it should do and how.
- Internal IT - too much work, too little appreciation = not much motivation. Group them with a “team” of hastily assembled junior Superheroes from Accenture, and boy, you’ve got no time for sexy; you are happy if the code compiles and does just barely enough so that you can move on to the next release.
- There is never enough time and money do to things right. Enterprises have a huge number of priorities they need to juggle, and making their employees happy isn’t nearly as important as making them productive (as if these two weren’t interconnected), and by productive the suits usually mean an insane screen with lots of grids and forms generated from database tables (100+ attributes to handle), so that the poor schmuck doesn’t have to navigate anywhere, he’s got everything “at his fingertips”, and he does and they bleed at the end of the day, but who cares.
Here I stumbled onto the answer: the Enterprise doesn’t usually look at its employees with the same CRM-fueled passion as it does at its customers. They are, after all, a column in the Expenses section. So why bother? They cannot switch to a competitor’s application should they dislike what they’ve been served. Damn, they can seldom change their desktop background; the cubicle slavery doesn’t allow for neither software choice nor simple self-expression.
I believe this is changing; SaaS is playing a huge role in it, and so are all the gadgets we buy that free our mind and scratch many itches. As we move from the purely utilitarian to the beautiful (compare the first CD players with PS3), the workplace is going to change, too, and so is enterprise software. In its own clumsy, passive-aggresive, uninspiring way.
PS For a sober look at the subject, read Jason Fried’s post on Why Enterprise Software Sucks.
PS II: I concur with Nicholas Carr:
Sphere: Related ContentBy perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use. Give Scoble credit. He’s asking the right question, in his own strange way.
Agile analysis, waterfall delivery
ITERATIONS, SCHMITERATIONS… Many a developer shop claim they are using an agile (as in RUP, not XP) approach, yet when time comes for them to put money where their mouth is, they are doing the ol’ good Waterfall.
Part of the problem is - the Customer. The Customer wants to know, up-front, what the application will look like.
But - although there is some truth to the old saying that all software would work perfectly if it weren’t for the users - blaming the customer is rarely a sound business tactics.
Why would the customer need to know exactly if he could trust the vendor implicitly?
Yes, trust. So many failed projects on their books, few companies have faith in vendors’ competence. They put provisions and clauses in the contracts so that they can sense an impending catastrophe before it strikes. One of these clauses: the Analysis shall deliver a complete specification of the final product.
Poor analysts.
They become designers, software architects, and documentation makers. Rarely do they have time to spend on their favorite subject, Requirements. Meaning the requirements rarely make it into the design, which leads to a product not matching the client’s needs, which leads to … poor satisfaction and a little less faith, again.
Here’s a solution: think agile, and the Waterfall can work.
Some deception is needed. The analyst will create beautiful visual representations of the final product - be it UML diagrams, a GUI prototype, or web page demos. And he has to work the client to make him think this is, indeed, the product. It has to be logical and detailed and, yes, sexy. The analyst has to seduce the client so that he sees the final product even though he’s actually looking at an abstraction. One that is decidedly incomplete and open to changes.
Indeed, visual modeling is a great way to capture, verify, and test requirements.
I understand the Agile camp looks at diagrams with certain disdain. Truth is, diagrams have no value in themselves - the client needs the code (or function thereof) - BUT they have a tremendous power in that they suck the customer in. He has something to look at, to dream about. And in that process he can express his wishes better than through written word.
Of course, the visuals don’t tell the whole truth; they do, however, define a boundary for any requirements that can and will come later. Which can allow for some agile approach even though the process goes from Analysis to Design to Development etc. and doesn’t allow for requirements to be formally introduced once Analysis has finished.
The product will never look exactly the same as the specs produced by analysts. It might, however, be closer to the customer’s needs, and even if the customer notices the differences, I doubt he’ll complain.
Sphere: Related ContentAgainst division of labor
SOFTWARE CONSULTANCIES that are running on RUP have it all figured out: analysts analyze, programmers program, testers test, and project managers… well, who knows what they are doing anyway.
I am starting to perceive this division of labor as inappropriate.
Obviously, it has its benefits. The craft of software development requires so much ongoing learning that nobody could keep up with new languages, frameworks, and methodologies while working on projects and be a specialist in all disciplines of software. Hence we say, let analysts work with requirements, architects to turn them into design, coders to translate that in the appropriate language/platform, and testers make sure it all works reasonably well. Seems like a logical choice, doesn’t it?
Here is the drawback: by drawing thick lines between the disciplines, we emphasize their differences and make them separate while the opposite is desirable. The customer doesn’t need a requirements matrix, UML diagram, nor test scripts; and sure as hell he doesn’t care about source code. He wants to see his processes automated, his customers’ data kept clean and safe, etc. That won’t happen unless all roles involved in the delivery process know about each other.
True, most testers know that what they test is a program code, and likewise, analysts tend to have an idea about the program architecture they are implying when drawing complex class diagrams. I am not saying they don’t know anything; I submit that they know far less than they should.
A couple of years spent charting UML abstractions can make one think writing code is easy: just lay down the bricks as prescribed in the analysis document, and everything will be fine. Or, looking at it from a different angle, writing J2EE code for enterprise applications, year after year, can make one conclude the business proprietors are a bunch of clueless, desperate egomaniacs willing to throw millions of dollars at the latest buzzword (think SOA, think CRM, think BPM) hoping it will automagically generate satisfied customers, increase in sales, etc. When people don’t know the whole story, they can come up with some real strange ideas.
Writing good software is hard. Making it serve business needs is even harder. It takes a well-defined and reality-checked process, fearless execution, and lots and lots of guts to deliver. Here, I submit that all the people involved in software delivery need to be intimately familiar with the whole process in order to produce something useful. Sounds trivial, sure, but isn’t as obviously accepted as it should.
To anyone wanting to start a career in software, I’d recommend this: try to get your hands dirty. Try coding, analyzing, testing, and if they let you, managing, too, though I am a big believer in servant leadership when I think of software projects, so you may want facilitating (instead of managing) projects. Be a generalist: whatever you may want to specialize in will one day be obsolete anyway.
And when you find what suits you best, stick with it; if it’s Java or Rails, great, if it’s making sure the app does what it should, that’s cool, too. Just remember what comes before you and what follows when you think you are done.
Sphere: Related ContentDoes UML speak the truth?
I DELIEVERED A UML WORKSHOP to a group of my colleagues on Wednesday. They were all eager to participate and we went through many exercises. Given a rather vague assignment, they grouped into small teams, thought aloud, communicated beautifully, and came up with reasonable diagrams.
Throughout the workshop, we tried to design a web portal for a travel agency. I was as direct and clear about what I wanted as a typical stakeholder would be (read: not much). They were supposed to figure out what it was, and use their freshly acquired knowledge to create a model that a development team could use for the actual work.
Their Use Cases were more or less similar. Further into the maze of UML 2.0, similarities ended. The more tools a diagram offered, the more creative my students could afford to be. And they did: each activity and sequence diagram offered a unique view on the system being modeled.
UML is a language. It’s an abstraction layer that’s supposed to cover the underlying reality. And as every abstraction, it’s leaky. Some would argue that code is leaky, too, and I agree. The problem is, if you add another layer, are you moving towards or away from the reality?
Methodologies that are using visual modeling are assuming that visual representation of business requirements expresses the stakeholder’s intent better than his or her words. They might (not everyone has the writing abilities of a seasoned analyst) but they ultimately don’t tell the whole truth. They are useful abstractions but they are leaky. They cover just as much as they reveal.
It has been my experience that visualization is most beneficial at the beginning of the project when people - both stakeholders and the development team - need to find common vocabulary, agree on goals, and unleash their imaginative powers so that unclear needs can be materialized into working software requiremens that a programmer can solve. It’s the code that matters, and the more quickly it can be delivered, the better. However, relying on UML (and other visualization methods) to provide the complete truth is just as time-wasting as writing tons of specs.
Sphere: Related ContentRequirements vs design
THERE ARE 2 TYPES OF PEOPLE WHO PROVIDE YOU WITH REQUIREMENTS:
The first group has a vague feeling about their need. You need to find the spot that itches and scratch it. They’ll expect you to know what they are thinking and won’t talk to you unless you are finishing their sentences and materializing their ideas on paper. They are easy to deal with when you’ve done your share of similar projects and can be their partner.
The other bunch is tricky. They may or may not know what they need but they sure as hell will tell you how you are supposed to do it. Example:
You walk into a meeting determined to (finally) get to the matter; if it takes interrogation of the 3rd degree, so be it. You’ve recently had a training of negotiation and other soft skills, so you are pretty confident you will, at the end of the day, know what they really want.
After a short chit-chat, they cover the table with Visio printouts and tell you where the buttons should be, what color, how will Systems X and Y integrate, how exceptions should be handled (the form will turn red and the user will click away a series of error messages…), et cetera.
Now, what’s a BA worth his name to do?
Talk about requirements, and you annoy them because they obviously know what they want and you are wasting their time. Concede the point and discuss their design, and you might end up with a solution that - surprise! - doesn’t serve their needs in the end. Why? Because their needs were so obvious they haven’t been tested.
Which brings me to my point. Business analyst is a natural partner and advocate of business needs and should fight for their fulfillment with both PM’s eager to slash the scope and developers who just want to do their thing. And as a good advocate, he has the right to extract and validate any information from his client that he needs to build his case. And damn well test it is since the opposing counsel will use whatever weakness he can find.
This isn’t about “translating” business requirements into technical specs, as the popular misconception about business analysis goes. Translating would mean taking whatever the client says and telling developers to build it. But if you do just that, you are wasting the oxygen in the room since developers could take such orders from business directly - who said they don’t speak plain English?
So - burn those Visio printouts. They stand in the way of understanding and obscure, not convey, what the needs are.
Sphere: Related ContentBratislava: Lessons Learned
I’VE COME HOME from a six-months long assignment in Bratislava, Slovakia, and while I am not at liberty to discuss project details, I’d like to share a few bits that I’ve learned there. It might be relevant to you out there who are also engaging in requirements engineering and/or software delivery in general.
And no, I haven’t accidentally re-discovered America: it’s been yet another experience in a series of many, and this just happens to be the first time I talk about it.
I’ll try to put out a short series on the software delivery process as I see it from the Business Analyst perspective; this installment will target some process-related issues and likely be updated as I think stuff through.
PART ONE: Process
A well-defined development process that doesn’t stand in the way of innovation and at the same time puts clearly defined limits on it is … a Holy Grail, and as such rarely achieved in a production environment. Nor is it often attempted.
In my capacity as BA, I mostly work in a documentation-heavy, top-down process context, and that’s when I am lucky: it’s not uncommon to work in a completely ad-hoc environment.
Worst of all, many clients will have rigid rules as to how they want things done without thinking through what they should want in the first place. The developer is then put in a position of very limited power without having been given clear clues as to what he’s supposed to accomplish.
As a result, the business analyst has no choice but to define the process himself and fight for its implementation with both the suits who are used to being able to push requirements into development at any stage, and the IT that is either defiant and unwilling to lift a finger or lethargic after losing way too many battles.
You could object and say it’s the PM’s role to worry about the process, to which I say: it can be, but look at the big picture: PM isn’t as concerned with requirements as he (usually) is with putting checkmarks next to tasks and walking importantly through the hallways. (some offense intended).
It’s my prelimiary conclusion, then, that the BA is most competent to define the process (from requirements to implementation) where there is none, since he has intimate understanding of what the suits want and what the developers are capable of delivering. Unlike the PM, he is also concerned with the value being created and delivered as he is personally invested in seeing it materialized.
Next: requirements versus design (tomorrow).
Technorati Tags: software development, business analysis, software delivery process, sdlc
Sphere: Related ContentRe: still failing
HOW TO PREDICT THE OUTCOME of a software development project? Raganwald suggests, among other things:
Sitting here typing this, I think the company who can do the best job of predicting the outcome of software development projects is Inkling Markets. That’s because their entire business is about finding a way for people to communicate what they really think of something, not just what they think other people want them to say about something.
to which witten adds:
However, I think there’s an even easier solution. Simply ask people what they think! No need for fancy buying and selling of virtual shares. If the project manager just went around periodically asking people working on a release about their opinion on the state of the release, a lot of the bottled-up warning signs and valuable risk information could actually be communicated appropriately, well before the post-mortem.
Out of many ways to estimate whether a software project will be delivered, I think polling people involved might be the least reliable one.
Which doesn’t say much about, say, developers’ ability to predict their outcomes as it does about the collective psyche of a development team.
Not to suggest that good communication isn’t essential for every venture, including software project. But you know that people don’t just communicate to exchange information; there’s a lot of buying, selling, and power gaming involved.
So asking a developer involved in the project what he thinks is the success % triggers a method that ultimately produces a value designed to cover said developer’s ass while not really saying much about the project’s chances.
Holding a poll among kibitzers and bystanders might yield less biased results. If your firm has 100+ people, betting on projects would bring new energy to the watercooler chat, though I’m not sure how well would you sleep if you knew 70 of your coworkers say you’ll fail. In the end, such a game would bring more harm than good.
A possible solution would be to let the customer bet on your success. Instead of your PM giving a boring Powerpoint on a weekly status, the customer’s rep would give you an up-to-date score of your project based on the customer’s perception. And how could that be boring, ever! The customer isn’t a disinterested observer, but politics notwithstanding, he’s in it to win. And given the chance, he’ll tell you how he rates your work, no problem.
The question then is, do we as consultants, contractors, vendors ever dare to ask?
Sphere: Related Content-
Recently featured
-
Stay in touch
-
Blogroll
Promotion
