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.