June 29, 2011
Our user has commented nicely about Yoxel Personal sync in this Basecamp Answers thread (see last comment) https://answers.37signals.com/basecamp/2534-outlook-task-integration
Plus, we’re testing our contacts sync for Highrise and Google app: http://yoxel.com/highrise-synchronization.html
December 14, 2010
Here is how you could implement basic scrum story tracking without signing up with any project server, simply using email. You’ll need to use our desktop app Yoxel PCM which scans your email inbox to help you track conversations and identify requests communicated in them.
- Install Yoxel PCM, connect it to your email account (i.e. GMail), see how here
- Flag/Star those email threads that represent scrum stories in your email client (or start new ones directly from Yoxel PCM)
- Yoxel PCM starts tracking conversations that you have identified and also presents them to you as chats
- As a conversation progresses, requests and responsible persons are identified.
- Each responsible person marks his/her ownership of a story and attaches personal tasks to it, all in their own Yoxel PCM. All this info is shared with the rest of the To/CC list and everyone is aware of who the owners are.
- As the owners progress on their tasks they mark their status (active, inwork, complete). As the matter of fact the app can tell the 1st two states automatically. Others, monitoring the conversation, see all these updates.
With this server-less model you dont get to see gantt or burndown charts but you can track all stories simply over email and empower individual functional members to plan and track the tasks associated with them.
November 25, 2010
Many large companies are concerned about measuring their business performance. It is not always obvious which departments, projects, products, and customers are more profitable and hence where the company’s focus should be. One approach that is helping the large organizations figure out their profitability is called Activity Based Costing. The model translates resource expenses into costs of basic activities constituting higher level projects and processes and from their derives product/service/customer costs. Such an analysis compared to the revenues generated by the corresponding product/service/customer helps to decide how resources should be used more effectively to maximize profitability.
You can find more detailed explanation of ABC on the Internet, here is just one interesting quote from http://www.asaresearch.com/articles/abc.htm:
Many experts believe that the best method for measuring a business may be “Activity Based Costing”. Some accounting software products such as SAP, Syspro IMPACT Encore, and Deltek offer strong ABC accounting.
The ABC model has a number of problems though that make its adoption quite problematic:
… the process of calculating activity expenses through interviews, observation and surveys has proven to be time-consuming and costly to collect the data, expensive to store, process and report, difficult to update in light of changing circumstances, and theoretically incorrect, by suppressing the role for unused capacity when calculating cost driver rates.
So an alternative approach for estimating an ABC model, called “time-driven activity-based costing,” addresses the above limitations. It is simpler, less costly, and faster to implement. Here is a great paper explaining TDABC and how exactly it is better than the original ABC model: Time-Driven Activity Based Costing. One of the key elements is how you measure an activity, and TDABC seems to be doing this by estimating time required by an activity:
The one new information element required for the time-driven ABC approach is an estimate of the time required to perform a transactional activity. As discussed earlier, an ABC system uses a transaction driver whenever an activity − such as setup machine, issue purchase order, or process customer request − takes about the same amount of time. The time-driven ABC procedure uses an estimate of the time required each time the activity is performed. This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary. The time estimates can be obtained either by direct observation or by interviews. Precision is not critical; rough accuracy is sufficient.
I really liked the TDABC paper but I am sort of confused by these two statements:
- This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary.
- The time estimates can be obtained either by direct observation or by interviews.
I understand that if you have the estimates you do not need the interviewing process. But, how exactly do you obtain these unit time estimates? The 2nd statement says, by interviews. So, do we get rid of the interviews or not? I am not sure what direct observation means exactly.
In any case the TDABC model makes alot of sense to me, and I like the idea of using time measurements instead of purely transactional measurements (10% – activity1, 20% – activity2, … = always 100%). I even think that you can do better than just the estimates. Organizations that use project management tools capable of time tracking could be collecting actual time measurements quite easily (depends on the tool of cause) all the time. Anyone tracking their tasks for PM reasons would automatically be logging time spent on the tasks. All that needs to be done additionally is proper categorization and directing that data into one of those TDABC systems (i.e. SAP, AcronSys, …)
So I am thinking the time measurements earlier generated by interviews could actually be a natural by-product of the PM task tracking process and will not be time consuming at all. A PM product that makes it very easy for people to track time could basically enable ABC/TDABC models for measuring business performance.
What do you think?
Here are two more links with more information on TDABC:
November 18, 2010
My customers mostly were very reasonable, they would ask to provide a commitment date for a deliverable right away but would also be ok if we postponed the date later, as long as we communicated the change of plans to them early enough. Their own plans depended on our commitment dates and they wanted to be sure we were not forgetting about our agreements (I am only talking about bugs and enhancement requests here). Sounds like it should be quite easy to satisfy your customer, file all these customer requests in your internal request/bug tracking system and keep the customer informed on the progress. And yet it was really difficult to keep up with this seemingly simple process of providing commitment dates and timely updates.
The first problem was getting a date from R&D. Most R&D organizations are not driven by due dates, they are driven by release plans (where promises to customers don’t always win strategic marketing targets and other priorities). So, you can get commitment dates for the requests scheduled for the next release (1,2,3-6 months from now, depending on the methodology used) but only once the release planning has happened, which means you get the opportunity to find out ETAs of your customer requests only once per 1,2,3-6 months. Well, customer is already not very happy, has to wait for so long just to get the commitment. This vendor release based scheduling does not go along with the customer request/commitment based scheduling. Plus, you have waited for 1,2,3-6 months for the release planning to happen just to find out that only 1 or 2 of your 10 customer requests have been scheduled for the release. Well, I am quite disappointed also, I don’t have the commitment date for 9 out of 10 requests and my customer was hoping to find out the dates for all 10.
You could say your R&D needs to use a SCRUM/agile methodology, run 2weeks to 1month sprints/iterations and then they will be able to provide commitment dates more often (every 2weeks to 1month). Agreed, but, how many iterations ahead can you plan without defeating the purpose of the “agile”? Probably not more than 2 or 3, so again the chances are I will still be only getting a commitment for 1 of my 10 requests per 1,2,3-6 months.
So this is the reality, you only know more or less what features you will deliver in your next product release (iteration, if you use agile). As 37signals say “planning is guessing” and your next release is probably your best guess. Beyond that, who knows how requests will be prioritized?
But how do you reconcile this with the customer’s desire to see commitment dates for all its requests even if some dates are meaningless and will be re-negotiated in the future? The customer basically wants our best guess date for all its requests, including those that do not get into the next release. That is a challenge, don’t you think? One may say, “then give them arbitrary date” for those ‘beyond the release’ requests. And may be that is what we should do. Not giving any date is an option too I guess. But I am thinking, can we do anything better for our customer?
So the idea is the following, may sound quite crazy, but I still want to throw it out there. Usually once a request is filed in a request/bug-tracker it is assigned to a developer right away, in most cases to the right developer who will actually be working on it once the time comes and either “blocker” urgency or the release plan says, “go”. At the moment planning is a prerogative of a few chosen product/marketing managers who plan for the whole team and it may become quite complex, so they can’t deal with more than a bunch of most important requests. But how about empowering everyone on the team to plan? Lets say we give everyone a powerful work-hours calendar (that predicts time-off, meetings, maybe additional statistically derived unavailable time) to plan his/her own tasks. Come on, the requests are all already assigned to the developers, don’t you think they would not be able to stack them up in this smart calendar with their best guess time estimate for each to come up with a reasonable ETA for all the assigned requests? The chosen ones can help the developers with priorities (they know the business goals better) but, in theory, all requests (and I mean all that you find in your bug-tracker or better all that have ever been asked to be scheduled, not just the subset selected for the next release) can be scheduled easily as long as you de-centralize the planning and let everyone schedule his/her own work. And the ETAs will be more accurate this way, I am pretty sure, because everyone knows their own stuff better.
Now, consolidate all these individual schedules, and pick the top N requests that you want in your release, see where your release deadline draws the line. The best thing is that any request “beyond the release” has been scheduled also and has the best guess ETA. I would really be happy to relay that to my customer, that is the best guess he was asking for all along. What is even better, every time there is a new request in the system it trickles down into developer’s personal work-hours calendar where he/she plans it right away (may be reshuffles a few other tasks to accommodate changed priorities). We have all requests re-estimated and re-planned, we have our best guess for all of them, and the commitment date can probably be shared right away with the customer. Actually the scheduling developer sees right away which commitments he breaks when adding a new task to his calendar. At this point maybe we can re-negotiate the priorities with our customer? That is the power of de-centralization!
I would call this “continuous re-estimation” or ”continuous re-planning”. You don’t wait until the next release planning session, developers re-plan their tasks as soon as priorities have changed or new tasks got assigned. May be you don’t even need release planning with such a model, because you always have your best guess schedules ready and up to date.
What do you think?
November 17, 2010
- Desktop app syncing to a site and allowing offline work – yes
- Item prioritization – yes. Ant it is visual, in a unique work-hours calendar, so estimation happens right away also.
- Main and sub-categories -no. Unfortunately at the moment it is just main categories (task lists)
- Cross-platform desktop software – yes. It is a java app.
- Sharing between users or just public access to the lists – yes, if you connect it to Basecamp (in the futute we’ll have our own way of make tasks visible to others)
- Mobile support – no.
Other bonus points for the app is that it is closely integrated with email and allows tracking of requests communicated in email conversations so it is really easy to manage a thread, identify a request and attach a personal task to it which you can quickly plan/estimate in the work-hours calendar.