The very welcome and confidence boosting quote from University of Ireland-Galway below regarding woosabi.com’s sister company, InPractice and its Relationship Management software, should be a real fillip for all concerned with the development of woosabi.com Customer Relationship Management Software programme. The successful “Engine” running the InPractice Healthcare & Educational placements throughout the UK and Ireland (soon Sydney + Vancouver??!!??) is the the basis of the the woosabi.com business model for its Customer Relationship Management (CRM) “Engine” software……………………..

…………..Great news for InPractice = Great news for woosabi.com

Following the development and implementation of the application, Lorraine Kent from the National University of Ireland, Galway, said: “The new InPractice online application is fantastic! It was great to see the placement database up and running so quickly . It’s already saving time and confusion. It only took a little while to become proficient with the software and its versatility and ease of use is a joy! Best of all we are able to provide new levels of professionalism for our placement providers and students”

As of this week I’ve been using Woosabi to run my main job’s affairs (www.inpractice.org) and the three things Woosabi does that will benefit it are:

• Sorting an horrendous amount of email
• Automatically invoicing clients every month (fixed fee work)
• Keeping track of the jobs I need to do (and reminding me to do them!)
• Being able to do this on the move (I hate being at a client site and not being able to access email and invoice info - especially if it’s a long day there)

So I took the leap and became the second full beta client for Woosabi, which means if it loses anything I’m in big trouble.

I’ve got a job to do

How’s it doing then?

Awesome! I just logged onto my Woosabi account in a coffee shop to find 4 clients have new invoices waiting to go out (monthly fixed fee items) as it’s March 1st, their billing date. It might be nice to have a simple way to email them these now so I can cut down the amount trees cut down in the name of invoicing

From city to city

I also get a lot of email. My inbox from the past night, which consists of backup files, automated batch job reports, personal email and spam has been nicely filtered for me. What Woosabi has done is group all these by the sender, which allows me to go into my contact view, and see only their email.

Wouldn’t it be great to read an email that’s a request for work and turn it from an email into an actual job of work that would be recorded later for invoicing? Welcome to Woosabi.

All in all, it’s looking and feeling very solid and I’m starting to feel incredibly proud of our efforts.

In between developing the Woosabi product and building practice placement systems for Universities (www.inpractice.org) I’m trying to finish this book Dreaming in Code (this is why I’m doing my blogs at 6am in an attempt to claw some of my day back). The book documents the development of an Open Source Calendering/Personal Information Manager (PIM)/Email project that’s been in development for the past 5 years. It’s interesing in that it has quite a few functional similarities to Woosabi - I should stress that the similarities are quite generic and are shared by a whole slew of Web2.0 projects

One Vision

The main part we share is this vision (Vision):

Chandler - “Our goal is to serve the way people actually work, independently and together, particularly in small groups, a market segment we believe is underserved. Our belief is that personal and collaborative information work is by nature iterative and that the existing binary Done/Not-Done, Read/Unread, Flagged/Unflagged paradigm in productivity software poorly accommodates the reality of how people work.”

That could quite easily describe Woosabi, if we had sat down and articulated it that consicely!  But we never did and I’m hoping that where we succeed will be down to all the things we “didn’t do”. I’m not sure if that sounds dumb, belligerent or both as it’s 6am and my vocabulary is still sleeping downstairs (I’m in the attic) but bare with me and I’ll explain that bit of triteness (that’s the word I was searching for!)

God is in the (right) detail

The part of our little project that sets us free from the pitfalls of other large-ish development projects is we’ve thus far kept ourselves largely free from bureaucracy and the meeting moth syndrome - aka the overwhelming desire to plan and attend meetings, usually to discuss what you could be doing if you weren’t currently at a meeting and then to plan the next one, to usually co-incide with some large project milestone.

What we do have is a great development team that understand the product we are building. We didn’t spend months writing white papers and technical specification documents because we never had the luxury of time to waste on something that is superceded by working code and a usable product. Is that a chicken and egg situation? In my opinion, and I could be proved wrong if our product sucks, it’s not. If you have a development team that fully understand the goal (and it could be as simple as ‘to build a login screen” or as complicated as “build an email client”), you use your code as your project plan with the build’s usable functionaility as a meaure of progress.

Teamwork or no work

The one major document we do have is the product’s “Style Guide” which is totally indespensible and almost entirely visual (i.e.without text). This is pretty much the only document that the developers refer to (on a daily basis). Woosabi is lucky in that we’ve a very talented Product Designer who’s able to visualise with the developers the entire product before it’s built.

Which means the other thing your team needs is ‘trust’ which comes not from a creaking shelf of documents that people are pushed toward (”hmmm, it’s all in version 1.2 of the MRS+TFS, now go away I’m trying to look busy”) but from outward, visible signs of work.

Successful IT projects come from having the right people and a good product that is visibly improving. Getting there isn’t easy but in my opinion you need to trust in your idea and build your product.  Not just a dream of one.

So we’re just two days shy of March 1st - our target date for launching the product for beta testing (insert pun of choice using the word beta here). And using the immortal refrain of backseat drivers and children everywhere:

“Are we there yet?”

Before I answer that I just want to have a word about deadlines and whether they are helpful or not. Personally, I believe they are vital. They help focus everyone in a team. They also help you make difficult decisions, such as ‘will this bit of functionality make the cut’ aka ‘does the product really need this?’. If there’s not enough time, there’s not enough time - unless it’s a core part of your product. Deadlines also tell you an awful lot about the people in your team, their abilities and their thinking under pressure.

“Tea cups and tantrums”

The World Cup winning coach Clive Woodward hilariously and without any embarrassment calls this T-CUP, “Thinking correctly under pressure”. People under pressure will always fall in to two groups when confonted with a problem: one type will find a way to solve it and the other type will find a way not to solve it. The more important part is to realise that both types will try to ’spread’ their viewpoint throughout the team. One is positive, one is negative and pressure will show this up everytime.

I once inherited a development team (not as fortuitous as it sounds) which had a particularly lazy developer within it; when it came to Crunch Time he was totally unable (unwilling might be more accurate) to estimate any of his work and rather than aim for something and miss he completly froze. Instead, when asked how long a certain job would take, he replied with the following gem that has stayed with me ever since:

“It will be ready, when it’s ready. I work by the ID credo”

Which I suppose is fine if you are in fact working for ID, the developer of, at one point, the definitive First Person Shooters (Doom & Quake). Not suprisingly I met with the CEO and we made the decision that the programmer should contact ID games to see if they had any work for him. Even with a deadline looming, I felt it better to jettison deadweight and keep the team positive, if overworked! Negativity is a deadly cancer in a development team and must be cut out immediately.

“I love deadlines. I love the wooshing noise they make as they go by” - Douglas Adams

The other reason deadlines are important is that they a vital piece of external communication. They tell your customer when something will be ready. It also forces you to communicate with your customer during development if the date looks like it’s going to slip. Better to talk to them, get their feedback as something that is pushing the deadline back could be cut if they deem getting the product more vital than having function x working. Of course, by doing that you put pressure on yourself to deliver and that’s the nature of deadlines (the Etymology of that word is quite stark). Without being too glib, if you don’t like deadlines then product development is definately the wrong job for you.

So are we there yet?

Yes. Actually, after that massive preamble, ‘Yes’ doesn’t feel a big enough statement of euphoria really so feel free to insert the profanity of your choice here: #$%*** Yes!

It feels really amazing to say this. We’ve a few little glitches to sort (well, that’s what beta testing is for) and some polishing to do but amazingly we’ve hit our March 1st deadline. Which considering we only have two engineers on the project, one of whom is a recent graduate and the other has a full-time job, this is phenomenal. In fact, I’ll go further than that, it’s nothing short of miraculous and proves you do not need big budget development teams for startups. No, what you need are these two things (assuming you’ve the ability): Positivity and Dedication.

Okay, better crack on, I’ve got another project whose deadline is next week! Where’s that coffee!?