-
About
Notes and views on CRM, open business models, and what the Web means for customer relationships. [more]
-
Speaking at:
IIR's Mobile CRM, Bupadest, Dec 2008
Telecoms CRM, CEM and User Experience 2008
Linkblog
Photos
Crowdsourcing blame
ONE THING I DON’T LIKE about working for large organizations is the moment when something goes amiss. This one requirement that wasn’t analyzed enough blows out in your face, or that bug you thought was fixed turns out to be alive and well, and all of a sudden, there are meetings, mass emails, other meetings, and yes, yet more meetings to come.
All orchestrated so that the person responsible is found. Why? If the problem is serious enough, there may be consequences, if not, the goal isn’t really finding the guilty party but making sure that everybody else is innocent. Then everybody laughs and the meetings are over, without any follow-up as to how to prevent future mistakes of the same kind.
Either you are serious about finding the culprit and teaching him a lesson, or you realize that software development is part craft and part magic and that mistakes just happen; either way, there is a point to be made. But this?
Small teams do both: they recognize individual contribution and the inevitable shortcomings of every member. Larger groups tend to focus more on member safety; there are business goals, sure, but the primary goal is keeping the status quo. After all, the company is big, so we might just as well do our 9to5 and go home.
It pays to know what your client’s culture is. When it’s an agile, lean operation, quality just might be your job #1. Other times, you as a software developer, project manager or analyst aren’t really an IT worker but a therapist. Just make everybody feel good about themselves: that’s often what our work is about.
The role of BA
I’VE ALSO HAD A PROBLEM classifying the role of Business Analyst as a bridge between business and IT, but if the Agile movement says IT should understand what business needs, I am not hopeful that just being able to come up with “better solutions than the business people can develop on their own” is good enough. Either business people will never understand technology well enough or IT folks won’t get the business needs well enough; but then, there would still have to bea bridge to cover the gap.
Indeed, when BA is staffed in IT, he becomes a documentor, an interpreter, and above all a tool of IT interests.
Therefore, I am convinced a business analyst on IT projects should be a member of the business team and as such play under their colors - as their advocate. If it means going head-to-head against IT, so be it. So often the programmers know full well what the business *really* wants, and don’t do it because it’s too difficult, costly, etc.
That’s not to say BA should necessarily push all ideas regardless of their merit; as Kevin says, he should be able to propose better solutions - based on his in-depth understanding of his colleagues’ needs. He should work with requirements as every good advocate should - with his critical faculties turned on.
Technorati Tags: business analysis, software development
Testing: not a service but a way of doing things
Johanna Rothman reminds us that testing is not a service but an integral part of development. I would go even further and say that testing is - or should be - excercised regularly at every stage of a software project, and not only there. Testing provides the much-needed touch of reality for our goal-driven activitites. That’s to say, as soon as we define goals, we need to test that they are both desirable and attainable, then devise ways to reach them and again, test them, and so forth.
When testing is left to testers, the following will happen:
- the analyst won’t bother reality-checking the requirements
- the programmer will be casual about the quality and robustness of his code
- the business folks won’t start reviewing the product until it’s been developed
It’s much more costly to change things at the end of the project that at the beginning, and it’s been the agile methodologies that have tried to answer that by giving everybody involved an early look at the product being developed. But that’s not enough. Before a project is conceived, there is a business need that’s supposed to be satisfied, and quite often its importance is sadly overrated.
The biggest tragedy of failing enterprise projects isn’t that they aren’t delivered on time or on budget. It’s that they’ve been started at all.
Sometimes, there’s too much money and too little time to think it over.
The human side of software delivery
THERE’S ONE ROLE missing in all software methodologies known to man.
The therapist.
There are analysts, programmers, project managers, and of course the “stakeholders” - the people footing the bill. And they all want the thing developed, delivered, and used. Yet, come the migration time, the Big Bang roll-out, blades are drawn out and mouths get dirty and there’s yelling and ghashing of teeth.
Because no one really knows if the thing is going to work.
The uncertainty is driving people nuts. Even if all known bugs are resolved and closed, there’s still plenty of unknowns. Maybe the testing wasn’t as thorough or honest. And maybe we haven’t thought of all the use cases.
And with the KPIs and quarterly bonuses on the line, no wonder that putting a system into production is such a drama.
It’s as if you built a bridge not knowing the first car to cross it would make it to the other side.
But you know what? Rarely do information systems have such a life-and-death import. Dollars might be at stake, lives - not as often. Which is why, at the end of a project, all team members should have a sit-down with a licensed psychologist who would tell them: good job, and if you screwed up and that printing routine isn’t going to work, too bad but life goes on. And you’re gonna fix that on Monday.
CRM From the Stone Age
Are CRM vendors reluctant to embrace, uh, the virtues of social media or CRM 2.0 if you will?
CRM companies have been soooo slowwwwww to provide the toolsets for social media and collaboration that I began to look elsewhere to see who would provide the suites for it. For some reason, the entire industry has been acting as if the tools that would allow customers to engage with a company aren’t important to, ummmm, customer relationship management. That’s the “customer” in CRM which, in case you haven’t figured it out CRM industry, equals the “customer” in customer engagement and the “customer” in customer experience and the “customer” in co-creation of value.
I have thought long and hard about not ever offering a commentary that is general and generalizing in nature, anymore, but I just can’t resist a cheap shot when offered a chance. To me, CRM 1.0 (that is the big, fat, multi-million-dollar implementation of a packaged software cleverly marketed as a way of reaching your customer base and getting to know it) is not as much creating a “science of business from the art of life” but quite the opposite: sucking the life out of the art of business and creating a lifeless science out of something that is essentially a relational and vital play.
I am not saying, intentionally. The road to hell is paved with good intentions, or whatever the saying is.
And I am inclined to think that BigCos are eager to have a “relationship” with every one of them customers, and pity that they are at the same time so obsessed with ‘control’ because the vendors know it, and boy do they know how to exploit it! Why would every mundane piece of software have “management” stuck somewhere in the middle of its name? It’s all about control, or the illusion thereof.
CRM will be a fraud as long as it’s got the “M” as its middle initial - it’s as simple as that.
And Paul’s post on CRM on the Hill says as much, in so many words:
You realize that not only is Congress at the CroMagnon stage when it comes to thinking about CRM technology, but the level that they are at when it comes to the programmatic, philosophical, strategic and cultural core of CRM is downright primitive. Their actual interest is not constituent engagement, but constituent avoidance or constituent deflection. (Kissingerian policy? Kidding…). In fact, I spent the day yesterday in Boston with Denis Pombriant, who is one of the leading CRM analysts in the world, and he called it, while chuckling, “Defensive CRM” - good for driving, not CRM.
But is it only the politicos who think this way? I think not. That’s the default way - it’s easire and it offers more short-term benefits.
CRM has been marketed and used as a tool for control, not engagement, not a conversation. So the vendors would be stupid to change their ways - as long as the buyers keep buying. Why would they?
Things are changing, though, and I think Salesforce’s move to open up their platform will prove to be a turning point. There’s a vendor who’s brave enough to give up control. It’s totally counter-intuitive, and yet I think it will prove to be a winning strategy. Because in the customer ecosystem, the company realizes it isn’t in control. And the sooner it does, the sooner it starts having the, you know, relationship that it seeks to have with its customers.
Mission Critical, Really?
A JAS Gripen crashed in Sweden this weekend. The Czech Air Force has several of these, and the generals have grounded those used for training until the manufacturer explains the reasons for the crash. Supposedly it’s a “software thing”, quoting an unnamed pilot who’s admitted as much on tv.
Whether it was the plane’s software that caused the pilot to be ejected from the plane and the subsequent crash is subject to investigation. If it was, I wouldn’t want to be in the shoes of the poor guy responsible for that particular piece of code… but that’s beside the point.
For those of us who have been embedded in the “mission critical” world of banking & telco IT, it’s a much-needed reminder of “mission critical” can sometimes mean. And that there’s IT beyond the enterprise, that it takes brains much sharper than ours, and that even there, mistakes happen - and costly they are!
Using wiki for bug-tracking
AS BUSINESS ANALYST, I’ve been involved in a small project in Bratislava, Slovakia. Now that I wear the tester’s cap, I am having the dubious pleasure of seeing my design materialized on the screen. And I am helping developers to debug the thing.
The 4-person team is using a wiki to track issues, and I quite like the casual feeling. We could use a “fully dressed” solution like Bugzilla. And if the team were bigger, we’d have to.
The joys of using “undressed” or “partially dressed” processes & tools are sadly underrated. Companies love to grow and adopt “mature” frameworks to prove they are growing responsibly. That’s why we have RUP and CMM(I) (and why lots of techies wear suits). But sometimes the solution that barely does the job is a whole lot better than one that offers a myriad of options and forces you to follow a process.
The wiki just does what we need: I manually add an issue into a list and a developer will color it green once he’s done with it. Simple to the point it doesn’t feel like work. It’s more like an impromtu conversation. And the job gets done fast!
I’ll recommend this to any small software team: travel lightly, and you’ll get there sooner and with fewer pains encountered on the way. (Damn, have I just discovered Agile?)
Technorati Tags: testing, agile, software development
PS This is my first post that is related to what I do for a living. Perhaps I should re-think my tagline unless I do more of this. And the title, too, since there hasn’t been much of the classical CRM here. I love the way this blog defines itself regardless of my will.
Links for 2007-03-19
- Show me the money: “A key differentiator for businesses in the future will be their ability to attract high quality online networks of interesting and engaged users of their product or service and then delivering access to those networks to their new customers.” Very CRM 2.0ish,very true. Though I am still wondering how is this applicable to the vast majority of companies who are, frankly, quite boring (mmm, ever had a crush on your gas vendor?)
- How to host a product/feature design party: “Want to design the next great web app? Upgrade your product, but can’t decide what to add or change? Add a new feature to your product, but can’t decide how to implement it? Forget focus groups. Forget endless meetings and brainstorming sessions. Throw an ultra-rapid-design party, and do it in a single day. This approach exploits the wisdom-of-crowds through a process of enforced idea diversity and voting, so no consensus, committe, or even agreement is needed. And it’s way more fun.“
Does Your Software Out-smart You?
I’m often confounded by software that’s too smart for my desires. Case in point this morning: as happens every week, several of the podcasts I haven’t listened to for awhile are marked with a little bang in iTunes. It’s stopped updating those podcasts because I haven’t listened to them in so long and wants to know if I’d like to keep downloading new episodes.
As far as I can tell, there is no way to turn this off. That’s life in Apple-land for you: thinking so you don’t have to.
Yeah. This is one of the reasons I did not fall in love with iPod and am still waiting for a Linux-based alternative (just kidding … or maybe not?).
On the other hand, my beloved has got one, and she’s happy precisely because Apple has done all the thinking for her and she, not being a geek, can focus only on what she cares about: listening to music. Everything that’s making that happen, processes and technologies, are completely transparent to her (she doesn’t care - she’s only concerned with the end result). And magically, the iPod is mostly right in predicting what she wants to do and how.
My take: the more competent you are with technologies, the less likely it is that you’ve developed your own way of doing things and the more choices you’re likely to demand. And chances are, you’ll be frustrated if the vendor assumes too much. You may be willing to accept the trade-off between simplicity and freedom (of configuration) and many have. Happily, the market has something to offer to just about everyone, and if you feel Apple is dumbing things down, well, you are free to look around for something more to your taste.
Technorati Tags: itunes, ipod, apple, linux
How about unit-testing “Hello World!”
GILES BOWKETT IS GETTING SERIOUSLY PISSED about the FizzBuzz kerfuffle that has rocked the blogosphere as of late. I can see why: a simple test that’s supposed to weed out people totally unqualified for a programming job has become an idolatrous ideé-fix with coders around the world hacking implementations in all programming languages known to man. What a waste of time, except programmers are prone to getting lured into various time-wasters (well, at least I used so).
But I’m not re-blogging his piece to argue about FizzBuzz. He received a Java implementation thereof and noticed how bureaucratic and inflexible it was, especially given the simplicity of the task. He writes:
You need to be flexible and adaptable in business. This Java solution packs layers of beauraucracy onto what might be the simplest programming problem in the world. Layers of beauraucracy have the functional result of impeding change — consider how my solution, you can change anything, whereas the Java one supports some changes and not others, and the developer’s assumptions about what changes may or may not be necessary shape the eventual range of what changes are possible.
But the sociological result of layers of beauraucracy is the real danger here. Sociology is much more important to software development than people generally realize. The sociological effect of Java, in this case, is encouraging conformity and limiting imagination. [...]
Anybody who’s ever seen a software project fail or even falter knows that if you cover every reasonable variation, you’re going to build a whole lot of options that your client or users will never ever use or even see, wasting time and money in the process, while at the same time building something which can bend at every join except the one they need to flex. You shouldn’t cover reasonable variations. You shouldn’t cover any variations. You should code the quickest, simplest solution you possibly can, even if it looks stupid as fuck, and then if your client or your users need some change, you should choose the way to do it which requires the absolute minimum of work.
Amen to that, brother.
Technorati Tags: FizzBuzz, Java, programming
-
One man's microISV
Playground - an on-demand business productivity tool focused on getting the right things done. -
Recently featured
-
Stay in touch
-
Blogroll
Promotion
