Wednesday, September 24, 2008

Using VIC: Managing Calls

"Out of the box" VIC CRM is geared toward the worker who spends most of his time in front of the computer and on the phone. When you create a new JournalEntry the default JournalEntry type is always "Phone Call". The rationale here is simple: when you receive a phone call you need to be able to start documenting it as soon as possible, with no delays at all. Other systems require you to gather some information about the contact before you get to the call record, but VIC does not.

Once you're in the JournalEntry you can add the contact information from your Index (or you can post "ad hoc" contact information), and you can change the type to any of the others supported by the Journal: Phone Call, Meeting, Conference, Product Demo, Service Call, Task, To-Do, or Trade Show. You can also edit the categories, assign it to a Project task, or update Contact information, as the info comes up and as you have time.

There are a number of different ways that we can initiate a Phone Call JournalEntry. The first is simply to click on "JournalEntry" on the "Create" tab of the navigator pane. This creates the blank JournalEntry and you add the name. If you're in any view that contains contact information you can click on the "Dial" action button. This gives you the Dial dialog, which will let you select the phone number and create the JournalEntry at the same time.

The document can also track the duration of the call. Just click "Now" next to the end time when marking it complete. The important thing here is that the body of the JournalEntry is immediately accessible.

Sometimes you want to follow up an email with a phone call (or meeting). In the email, pull down the Tools action menu, then select Convert to JournalEntry. This will create a JournalEntry which you can then schedule. This will include all of the contact information from the email, as well as the body of the email for reference.



Tech stuff:

I've been asked how to implement the dialer generally in Notes. To do it you would need Domino Designer. I have only tested this in Windows, though it should work on Linux under WINE if TAPI32.dll is provided. It relies on the Microsoft Telephony API, which is provided by any of a number of TAPI clients. What's difficult is finding a utility that does only TAPI phone dialing, and doesn't try to hand you Yet Another AddressBook as well. One that really fits the bill is Jacek Koslowski's Dial Engine Pro. It's unobtrusive and does exactly the job required. If you don't want to spend money then the there's the Windows Phone Dialer (dialer.exe) that's distributed with Windows XP. VIC will use the Windows dialer if nothing else is in place, so dialing always works on this platform.

If you're using Notes without other modifications, then the change would need to be made to the Addressbook. You would put the script into a script library (for instance, mine is in a library I called "CratchitTAPILibrary"), then you'd add an action button to the Contact form that would include the following LotusScript:
Use "CratchitTAPILibrary" ' or whatever you've called your script library
success=fDialNumber(doc.OfficePhoneNumber(0), doc.FullName(0))
If you have trouble following these instructions then I'd recommend a good basic book on programming in LotusScript. Amazon.com has a good selection. Another invaluable resource is the LotusScript to C API Programming Guide by Normunds Kalnberzins.

Here's the whole script. Yes, it is this easy:
Declare Function tapiRequestMakeCall Lib "TAPI32.DLL" (Byval DestAdress$, Byval AppName$, Byval CalledParty$, Byval Comment$) As Long


Function fDialNumber(cPhoneNumber As String,cCalledPartyName As String) As Integer
Dim nReturnCode As Long
Dim cApp As String ' What are we using to call?
Dim cComment As String ' whatever you want.

REM replace this stuff with values for your app.
cApp = "VIC CRM"
cComment = "Lift your handset now."

fDialNumber = tapiRequestMakeCall(cPhoneNumber,cApp,cCalledPartyName,cComment)
If fDialNumber <> 0 Then
' there's no point in making this robust,
' since the Microsoft phone dialer will give you
' detailed status on the screen.

Print "Call failed!"
End If
End Function

Monday, September 15, 2008

Using VIC: from Project to Sale

In my last Using VIC post, I described how to use Projects to manage complicated groups of tasks. These can be generic projects of the sort you'd use Microsoft Project for; or Sales oriented methodologies to help you manage a sale from working the lead to closing the contract. I also promised I'd show you how to turn the Project into a Sales Order and an Invoice.

Remember that a Sales Project includes a Products tab that allows you to put together a wish list of products. This helps you estimate the value of the potential sale. When it comes time to complete the sale you may want to turn this list directly into a Sales Order to reduce the amount of typing you can do. In VIC, this couldn't be easier. You simply select the Project in one of the Views or open it, then pull down the "Create" action menu, then select "Sale".

That's it. All of the customer and product information will be included in the new Sales Order. You should edit the pricing to make sure the taxes are calculated properly (at a minimum, just edit then resave the prices). When the Sales Order is approved, you can turn it into an Invoice with one click (while the Sales Order is open for editing, just select "Make Invoice"). By default, any project is turned into a Sale. However, you can save that sale as an Estimate (a quote) by clicking "Make Estimate").

I'm tempted to end the post there, because we've pretty much accomplished the task. But let's take some time to look a little more closely at the Sales database.

VIC Sales is not, not, not an accounting package. It does generate sales orders and it does generate invoices; but these features are basically there because I've been largely dissatisfied with the general state of open source accounting packages for small business. I'll resist the urge to rant about the reasons here, but the ironic outcome is that VIC Sales, poor as it is, is a placeholder for the accounting system that I'd like to use, but which nobody yet produces.

VIC Sales was originally conceived as a place to simply list, in a convenient form, the major sales we've made to each customer. That allows us to measure sales performance and get some reports. If there were an open source accounting package that I actually liked, I would code a link to that to simply import the data from accounting. If you're adapting VIC CRM for your company, I recommend that's what you do... have an interface to pull in your sales info from your accounting system. The reason for this is that VIC allows you to have Categories and additional metadata that your accounting system may not have; and because the people who need the reports may not have access to your accounting system. Since not everybody is going to have an accounting system or want to modify VIC, I've included the ability to create and edit rudimentary Sales Orders and Invoices here. A small consultancy may be able to manage with just VIC CRM or VIC + Quickbooks/GNUCash/TurboCash. A lone consultant or salesman can certainly do so.

I'm going try to scare you off first. Here are reasons to not use VIC CRM for accounting:

  1. There is no audit trail.
  2. The method of calculating taxes stinks.
  3. No General Ledger, Purchase orders, or Accounts Payable.
  4. Accounts receivable is rudimentary.
  5. There is no audit trail.
  6. There is no proper breakdown by accounting period. VIC displays a view by calendar year and month, but that's about it.
  7. There is no audit trail.
  8. It conforms to no generally accepted accounting principles.

That said, there are plenty of small businesses that generate invoices using Microsoft Excel templates. If your business is one of those, you'll probably find VIC Sales to be a big step up. And I can think of some fairly good reasons to use it for generating invoices and then just entering the summary information into QuickBooks.

First, VIC keeps the entire sales process in one interface. Your Product and Sales brochures in the VIC Library form your inventory; so if you keep those current for sales, they're also current for billing. That works in reverse as well. If you keep your inventory straight, then your sales materials will never be out of date.

Also, VIC CRM does a "stupid pet trick" that no accounting package I know of can do... it can treat your Calendar entries as if they were inventory! It's a bit like Time Billing, only easy. Here's what happens: say you're consulting. You've made several phone calls on behalf of a customer and perhaps you've made a couple of site visits. You've documented the activities in your VIC Journal and you've checked the "Billable" checkbox for each. The VIC Index contains a bill rate for this customer. When you create a Sale for this custimer, then you can add products from the VIC Journal instead of the products file. The inventory list displayed will be all unbilled JournalEntries for that customer. When you add it to the Sale, VIC will calculate the charge based on the actual duration of the activity as documented in the Journal, times the bill rate. No more estimating how much work you've done. VIC knows. Doing this will mark the original JournalEntry as "billed" and it will link that JournalEntry to the Sale or Invoice. That way, as you browse your Journal you can immediately see the invoice that included that JournalEntry as a line item.

If you're like me, sometimes you do work and purposely don't bill for it. Or you may have a customer on a support contract. If so, I recommend that you still generate an Invoice. The reason is simple: If you don't bill for services the customer has little idea of the value of the services he's receiving from you. But with VIC you can list every single moment you've spent on that customer's account. Discount it 100% so that you're sending a zero-balance bill (the line items will still show the value), and include a comment regarding professional courtesy or referencing their support contract. Even if you don't do this periodically, the ability to do this can be invaluable when it's time to renew the support contract. The sales pitch boils down to "here's what you would have spent this year without a contract..." and the customer can easily make his decision.

VIC Sales lends itself easily to workflow. There's no particular workflow built-in (this is the sort of thing that differs from company to company, so it's a custom feature), but VIC Launch contains a dashboard that lets you work as if it is. The Financials dashboard is split into four quadrants. The left side represents potential income; the right side represents income owed to you. So the four quadrants are as follows:
  1. Unbilled Journal Entries (upper left). These are Journal entries that are in a "complete" status and are marked as billable, but haven't been marked as billed. They represent potential revenue for which you haven't billed.
  2. Open Sales Orders (lower left). These are sales orders that haven't shipped. "Shipping" in consulting can be a flexible term. I use it to represent work that has not yet been approved.
  3. Invoices not sent (upper right). These are shipped, but not yet billed. Your pending action here is to print and mail invoices. I print them to PDF and email them.
  4. Open sent Invoices (lower right). These are invoices for which you're awaiting payment from the customer.

Once an invoice is paid off it drops off of the Financials dashboard. Also, estimates are not displayed in the Financials dashboard (Estimates are "what ifs" and do not represent potential income). All of these dashboard views are summarized so you can see totals per customer and a grand total. And of course, with Domino Designer you can tailor them to your needs. A manager viewing this dashboard on the server will see the numbers change as the documents are processed by the sales and/or accounting staff.

So VIC Sales has a few things working in its favor. But as accounting goes, my official statement is that it might be better than nothing at all.

For robust accounting I suggest your company standardize on a real accounting package. Larger companies would do well to use VIC as a method of having the salespeople communicate sales to the accounting staff. They can then create invoices into a standardized accounting package. Customization could automate this link.

Thursday, September 11, 2008

Guinea Pig Wanted.

For several years I've been distributing VIC CRM without any setup program. As a result, only hardcore bleed-yellow Lotus geeks have been able to get it to work without assistance.

Well, I'm just about finished with the VIC Installer. If you're running Notes and want to be the first kid on the block to try this out -- pre-release -- email me with "Guinea Pig" in the subject. You shouldn't have any trouble finding my contact information on Cratchit.org.

...and don't ask me why it took so long to get an installer done. For some reason I was dreading the task and was hoping somebody else would do it. Turns out, it only took a few hours once I rolled my sleeves up.


Sunday, September 07, 2008

Using VIC: Projects and Tasks

Last time I described how to use the basic features of VIC to facilitate the GTD (Getting Things Done) method of time management. This time I'll be describing how to manage a larger group of tasks as a VIC Project. If you're using GTD principles you would use Projects to schedule and manage complicated work that can't be done in a few sittings or by one person.

Projects is a new feature of VIC. There's an in-work implementation in the last release, and the next release (scheduled for October) will improve it greatly. It's a slight departure from VIC's original design as well. Originally, "Projects" was to be "Opportunities", and was to mirror the sort of functionality you'd find in other SFA applications like Relavis eSales and Maximizer. Then I realized that the sales methodologies I'd planned for Opportunities were generally useful for other more generic projects. Since I personally deal in generic projects more than sales, I decided to implement it.

Let's look at the high-level description of a VIC Project. There are two kinds: "Project" and "Sales" (and there's a third I'll describe later). A "Sales" project is what's referred to as an "Opportunity" in other products. It's a group of tasks that lets you work the sale to best advantage. Many companies have sales methodologies... a set series of steps that are followed to close the sale. These are steps that are proven to work, so they represent a best practice. VIC Project allows you to define multiple methodologies for both sales and general projects. By setting them up in advance you can then apply an appropriate methodology to a Project, and the tasks will be created for you. The methodologies are sort of a template that can be applied after the fact. We support multiple methodologies because different "best practices" apply to different situations.

Why do we need to be able to apply the template after the fact? Isn't that backwards? No, it's just about everyone else that's backwards, as you'll realize with a moment's reflection. You need to initiate the project in order to size it and prioritize it. The methodology you use is often dependent on the project's size. It's a little cumbersome to track a project through its entire life using a tool like Microsoft Project, so most people don't use MS Project until the project itself is well advanced. They pretend they do... but most don't. In VIC Project, you simply create a Project document when you first think about it. It begins with a status of Pending. You can prioritize it, relate tasks to it, etc., because that's the only way you'll be able to really determine the effort and cost involved in doing the project. Users of MS Project and similar products usually have a lot of undocumented effort and cost.

Back to methodologies... as I said, a series of predefined steps. In VIC, these steps translate into Project Tasks. The Tasks have estimated start and end dates (and you can document the actual start and end dates); an indicator of percentage complete; some estimate of the cost and benefit... that sort of thing (and remember, it's customizable). Sales projects also have a tab to qualify the opportunity with some information about the target company, its size, your "gut" feeling about the opportunity, etc.; and they have a tab where you can link this Project with the products and services you hope to sell, basically allowing you to build an estimate of the value of the sale that you can later turn into a quote.

A "Project" Project, despite having a redundant name, is anything that's not a Sales project. It has all of the same features except there's no Qualification tab and no Products/Services tab. Moving on....

Once you've determined what methodology you're going to use, you select it within the Project, then apply it. Based on the estimated start date of the project, it will automatically create and schedule all of the tasks defined in the methodology. Each of these tasks has its own status tab with percent complete; a description of what the task entails; and some estimated start and stop dates. It also has a tab to document expenses and a tab where team assignments are made.

Now, if when you think of "Project" you think "Gantt Chart" you've got some re-thinking to do. I've been managing large projects for over 20 years, and have really never found a case where fiddling with the popular charts ever helped actually manage or track a project. They look pretty, and they're somehow expected, but they cause more frustration than anything else in MS Project (other than auto-leveling). They are the sorts of things that keep project managers busy while everyone else is working. So I don't bother with them. Not that I won't add the functionality in the future if enough people bug me for it, but I'm hoping that they'll like VIC's way better.

I was recently looking back at some of my early design notes, where I'd made this comment: "Some of the best-run projects I've seen have been managed schedule-wise with yellow sticky notes on a honkin' big paper calendar. That's very effective. People can break down the tasks onto different sticky notes, post them on the calendar, move them around, write in status. It works. I'm looking to do that sort of thing digitally, but with a lot more bang for the buck than simply using a schedule."

So VIC's way is to schedule the Tasks directly onto a Calendar. You can fiddle with the schedule by dragging your Tasks around on the Calendar as if they were the sticky notes that impressed me (so long as they're estimated. Once you're actively working on a task it's locked into the actual dates). If you drag a task, all of its dependent tasks are adjusted as well.

Keep in mind that this is a shared Calendar. Not only can it show tasks for all of your Projects, it can show Project Tasks for everyone else's projects as well. Multiple projects, one portfolio, one management tool. Now with all of these projects and tasks crowded onto the same Calendar, you may think that this will all get very confusing, but there's method to the madness. Sharing the schedule makes conflicts obvious. And you can filter to show only your own Projects, or a single Project. And the Calendar's not the only way to view your Project... there a View that closely resembles the traditional WBS (work breakdown structure... projectese for "list of tasks").

Now, anybody who's worked on a project knows that the tasks as listed in the WBS rarely fully represent the actual work done. For instance, something as simple as "write login page" doesn't necessarily take into account research into the reusable code libraries to see what can be adapted, etc. You could put that into the project plan, but it's not really sensical for the Project Manager to get involved in that level of detail. Sometimes you don't even know what the work will entail until you begin the task... this is often the case where you're engaged in creative work. The "100% rule", while fine in theory, is often either unattainable in the real world, or is too much information for managerial requirements. Your project manager may not have predicted all the work required and there's usually some bottleneck getting new tasks onto the project plan. We need a tool that will track and summarize your work anyway. So here's the best part if you're the one actually doing the work...

When working on your tasks, document them in your VIC Journal just like any other activity. There are two ways to go about this: If you're creating the JournalEntry directly in your Journal, then on the Associations tab there's a Project box. Just click the link and select the project task you're working on. If you're working with a Project Task, you can click Create, then JournalEntry. Either way this JournalEntry will be related to the Project Task. And if it takes you multiple sittings to get the work done, so what? Just document whatever time you spend on the task, whenever you spend it. Do this and you won't have to report anything to the project manager.

Here's the best part if you're the project manager... There's a View in the Journal that will show the number of hours worked by Project and Task. This View is accessible directly from VIC Project, so at any time you can see exactly how much real time has been spent on your project. No need to send emails, no phone calls, no need to shake down the team for this information. I particularly like the "no emails" part. Microsoft in particular seems obsessed with the idea of emails incessantly flying around from inbox to inbox like some unlikely Cirque du Soleil act... and I'm picking on Microsoft because they own the project management software market. This kind of routine information should centralized and managed by your project management tool, not spread all over the ether. So in VIC, you manage all your work in your VIC Journal -- there's nothing special about doing project-related work -- and VIC Project will pick out the information that it needs. Since all this info is shared on the server anyway, why make it hard?

We can get creative as well. According to PMBoK principles, "projects" have a definite beginning and a definite end. The PMI draws a hard distinction between projects and ongoing processes. We don't have to draw that distinction, though. For instance, a software developer might have to devote a certain percentage of his time to customer support. So let's go to the Configuration database and add "Process" to the ProjectTypes keyword list. Now we can create a VIC Process for support. (It's still a Project, but listing the type as "Process" keeps the type-A personalities among us from picking nits.) Let's have one Task for each of the chargeback codes for each department (or GL codes, or however you track this time in your organization). Just leave the dates blank on these tasks. Then, as you deal with helpdesk tickets simply document them in JournalEntries and relate them to the Project Tasks as you would normally, selecting Tasks for this process. When you're reporting your time you've got a live record of exactly how much time you've spent on supporting each entity. This is especially easy if you're using a Lotus Notes based helpdesk system... then you can use Notes bookmarks to relate your JournalEntries directly to the helpdesk tickets. The point here is that you should be able to find this flexible enough to accommodate creative uses of the tool.

Don't you love it when everything just works? Using VIC CRM it's perfectly reasonable for a company of 25 people or less to have more effective processes in place than most of the national or multinational companies I've worked for (and that's quite a few).

I won't kid you... there is still a lot of work to be done here. For instance, I plan to implement an option to lock tasks that don't belong to you so one person can't mess up another's schedule. I also plan to improve the scheduler with holidays and blocked out dates. For now you have to manage this carefully, but for companies the size of VIC's target user base (companies of 25 employees or less) it should be manageable. There are things that VIC Project doesn't do at all... there's no resource management beyond being able to assign team members to Tasks. There's no leveling. There's no critical path. I don't have dozens of people working on implementing these features either. It's just me. So far this is working very well for me, and hopefully I'll get some constructive feedback from people who understand the design limitations. This is not a full-featured tool, and it's not intended to be; the features I left out are the ones I never use in other products, and which aren't generally important to my target users. In most cases I never use them because I've never seen them done well, so what would be the point? What I'm hoping here is that the features which are so useful to me are as useful to others.

Finally... remember when I said that a Sales project (opportunity) allows you to build a list of products and services? Next time I'll describe how we can turn this into a Quote, a Sales Order, and an Invoice. We'll also see ways of managing JournalEntries so you never forget to bill a task.

P.S. I know that I'm breaking some widely respected rules here. I really don't care. Tools should always, always, always facilitate getting your work done. If the process gets in the way and becomes cumbersome then there's something wrong with the process. I firmly believe that the 100% rule is inappropriate when applied to creative work. As for the project/process distinction, VIC Project is a management tool, not a nitpicking machine.

Saturday, September 06, 2008

Using VIC: Getting Things Done

On a typical day I'll get dozens of emails ranging from newsletters and ads to requests for service (of various priorities). How do we turn these into actions? And how does VIC expedite the process? Does it work with GTD (Getting Things Done)?

If you're familiar with VIC CRM you already know that it automatically organizes your mail as it's imported into the VIC Journal. This means it's easily viewable by company, contact, or by any category tags you've assigned to your contacts. If you've full-text indexed your Journal you've got even more flexibility. Because of the flexibility of categories, VIC doesn't need folders.

I use the "My Mail by Date" view as my primary mail view, and import mail from my Notes Inbox (here's how that works). As with all Notes databases, the unread documents are marked with red stars. In VIC a new feature is that emails diretly addressed to me are also marked with yellow stars. This allows me to easily differentiate them from emails on which I'm copied or blind-copied. I pay attention to the yellow-starred items first.

For those of you familiar with GTD, the general rule of thumb here is that as you go through your correspondence, do immediately those actionable things that can be done in under 2 minutes, delegate what needs delegating, and defer the rest. Non-actionable items should be thrown away, filed for reference, or "incubated" for possible action later. (David Allen recommends going through all items top to bottom, but we all know that there are some items that are truly urgent, and VIC's ability to auto-organize your correspondence helps you to identify those at a glance.)

I read through the mail twice a day.Since all of my newsletters are categorized as such, I don't have to take any action to defer them... I just wait to read them during the time I schedule for that. The same for "Imported - To be filed": these come from people who aren't in my Index, and were imported because the subject matched my list of key phrases. (BTW, "VIC CRM" is one of those key phrases, so if we haven't corresponded before, put that in the email subject.) All actions without yellow stars are FYI... I'm not the primary recipient. I schedule time to read those later (it's the same as my newsletter time), so I don't have to do it now. It's deferring, but I don't have to take any action at all to do that. So here's what might happen to the mail I actually read:
  1. If I can take action, I do... this might be a Reply to the email, or forwarding (delegating); but it might be a Phone Call, or a Service Call, etc. In these cases I select Tools, then Convert to JournalEntry to add the action to my Journal Calendar. The new JournalEntry contains the body of the email so I have a complete record of the action I've just taken and its impetus. VIC's Dialer will dial the number for me, and the JournalEntry will accurately record the length of the call. If this is in reference to an open or pending Project, then on the Associations tab I select the Project Task to which it's associated. This allows me to report on time spent on a project with 100% accuracy.
  2. If I need to defer an item until later, I do exactly the same thing, except that I will schedule the call for later and check the "Set a Reminder" checkbox.
  3. If it's something that I need to defer, but I can't set a particular time, I'll still convert it to a JournalEntry; then I'll change its type to "To-Do".
  4. I might want to refer to something later. I can just leave it alone and find it later with the full-text search, or if I want to give it prominence I'll link or copy it into the VIC Library.
  5. An inbound email (such as a user's request for features), or a conversation, or a news story, or some frustration I've encountered during the day might inspire ideas for future work. I use my VIC Notebook to record vague ideas that I might work on "someday". I'll make a pending VIC Project of those ideas that are more solid.
  6. I don't see spam at all. Here's why. Once a week or so I scan the SpamTrap, but it's pretty quick since I'm just assuming these things are crap and I'm looking for something of interest to me.
To-Dos follow you from day-to-day, but aren't associated with a time-of-day. The danger with a To-Do is that the older it is, the more likely it is to become a permanent fixture on your list. Your brain will just stop seeing it: If you've ever worked with Microsoft Outlook you know exactly what I mean. So I never actually work on To-Do's as To-Dos... I convert them to the actual type of action I'm taking ("Task", "Phone Call", "Service Call", etc.). Generally, keep To-Do's to a minimum, and get rid of them as soon as possible. VIC displays To-Dos directly in your Calendar to encourage you to keep the list small... you should never have more than a handful. Your first action on any To-Do should be to nail it down in your schedule as another kind of JournalEntry. If you know you won't get to it until next Tuesday afternoon, then schedule it for then.

Except for To-Dos, JournalEntries record or schedule specific times of day. Like all appointments... they're either done or missed. VIC provides a "Missed Appointments" view to help you determine which were scheduled in the past but not marked complete. But you shouldn't need to use that view very often. When you're working on a task you're going to be interrupted sometimes... that's a given. So you handle it like this: Do as much work as you can. When you have to give up for the day, or you're interrupted, mark the JournalEntry complete! And schedule a follow-up! The follow-up will be the continuation of work. Scheduling a follow-up is done from the original JournalEntry; it links the original entry to the follow-up so you can refer back to your earlier notes with one click.

"But I didn't complete the task!" you may say. That's fine... you've done work. You've scheduled the continuation of that work. You need to be able to charge the work to a Project or Sale: these are two ways of tying complicated tasks together. I'll cover Projects in my next post and Sales afterward.

By the way, you may notice I haven't mentioned reports at all. There's no such thing in VIC because Views are superior. A report is static; a View is dynamic. You can actually click on any View entry to open the data item and examine or manipulate it. If you're desperate for a report, you can export a View to a spreadsheet or can copy it as a table and insert it into your favorite word processor, or you can print it directly.

Whew. All of that seems kind of intimidating as I write it down, but I use it every day and it's not intimidating at all. I record all phone calls and all actions the very same way... by documenting it in my VIC Journal Calendar. Emails become actions. In VIC, documenting and managing tasks are the same thing. Organizing is mostly automatic. Reporting is completely automatic. And when you see how Projects and Sales work to tie separate tasks together into manageable (and billable!) units I think you're going to like them a lot.

As you can see, VIC CRM is an awesome tool for managing your work, and it's an excellent expediter of GTD methods. More later.

Wednesday, September 03, 2008

Chrome: Google Does Evil.

Google's released it's own browser, Chrome. Other people are doing in-depth reviews, so I won't. (Here are a couple: ComputerWorld. ZDNet.) However, I'd like to pass on a few first impressions. In doing so, I can't help but make comparisons to my favorite browser, Firefox. I doing the review I found a MAJOR show-stopper for the adoption of Chrome, Docs, or any SaaS from Google. I'm saving the worst for last.
  1. The UI is minimal. Too minimal for me. I like the customizability of Firefox, and I like the ability to use themes. My browser should look the way I want it to.
  2. The functionality is minimal. Again, too minimal for me. One of the very best things about Firefox is the ability to use extensions, none of which work in Chrome. My browser should work the way I want it to.
  3. Speaking of work, Chrome puts "app shortcuts" on my desktop. This kicks off a minimalist window without browser controls, and frankly I don't see the point of it. At all. You want the users not to know they're using a browser? Why? So they can bombard Tech Support with questions about "desktop" apps that fail to work when the network is down? My opinion: it's a pretty dumb move that insults the user base. According to Google you're too dumb to use an app in a browser; you might get confused.
  4. I don't much like the way Chrome does bookmarks, either. Firefox's sidebar is superior in every way the cascading "mystery meat" menus of Chrome.
  5. Chrome is blindingly fast. That's a good thing. Nevertheless, I'm sticking with Firefox. The performance advantage of Chrome is significant but transient in a world where open-source makes all technology shareable.
  6. While some people like the "most visited" feature, I don't. My most visited websites are on my bookmark bar, as little unobtrusive icons. I know where they are and how to tell them apart. I do not need them thrown up in my face as giant thumbnails.
  7. I DESPISE THE EULA. In fairness, this is in part the licensing agreement for Google services, like Google docs. And it clearly gives Google a license to use your documents, even those that you think are private, or company-sensitive.
"By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any content which you submit, post or display on or through, the services. This license is for the sole purpose of enabling Google to display, distribute and promote the services and may be revoked for certain services as defined in the additional terms of those services."
The EULA alone is enough to put me off of using the Chrome browser, Google Docs, or gmail as a primary email address. I STRONGLY RECOMMEND THAT YOU DO NOT USE GOOGLE SERVICES for ANY company information. I'm all for freedom of information, but you should choose whether and when to release it. Delegating that right to Google (or any other company) is - to put it mildly - the most outrageously stupid decision you can make for your company.

I am aware of the revocation clause. I am also aware that Google dictates the "additional terms of those services". This isn't a negotiable thing. Once again... it's a bad idea to put your company's data in somebody else's hands. It's a monumentally stupid idea to give it to somebody who tells you in advance that they intend to use it for their own purposes without so much as a "mother may I?"

Use the combination of Notes & Domino. Come on folks, it's cheap. It gives you customization and mash-up capabilities that its "competitors" just flat can't touch. It does more than Google or Exchange & Outlook and can be accessed with a browser. It has a complete ODF-compliant office suite built right into the Notes client. There is nothing, and I mean absolutely nothing, that Google gives you that justifies that draconian, lop-sided licensing agreement.

Google's credo is "Do no evil". I think they've forgotten that.