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

Just want to add here that we can do the same now for Zoho Projects: http://yoxel.com/zoho-project-management.html  Huddle connector is also coming.

Plus, we’re testing our contacts sync for Highrise and Google app: http://yoxel.com/highrise-synchronization.html

 

 

 

 

 

 

 

Is Your Inbox Overflowing?

January 24, 2011

I ran into this article today, It’s time to deal with that overflowing inbox, which re-iterates what we all experience with email today:

1) The growing number of e-mails, she explained, is hampering productivity among so-called knowledge workers who rely heavily on e-mail to get their jobs done and to stay on top of their personal lives.

2) “People with more than 100 messages in their inbox are less satisfied with the quality of their projects, more behind on them, and less likely to know what they need to work on at the start of a workday,”  …

 

And another interesting fact, pointing out that corporate knowledge workers use email alot for project collaboration:

Right now, the average corporate employee spends 25 percent of his or her workday on e-mail-related tasks, according to Radicati, compared to 14 percent on face-to-face meetings and 9 percent on the phone.

The article suggests to clean-up your inbox regularly and delete email.  But that, I think, is the option you’re left with when using your traditional email client. Email may contain valuable data and so removing it regularly just to make yourself more productive is not the best approach. I believe, organizing email better in ways that make it easy to find and know what is important at the moment, is the way to go.

You’ll probably need an additional app for this, or a new generation email client. GMail is a good one, but how do you manage your MS Exchange email with it? Xobni is an app that could help you with that though.  We’re also developing the Yoxel PCM app that will help you manage email threads/conversations better for more productive project management.

Cheers

Email or Email Client?

January 12, 2011

Great article from 4spires,  Email Is Flawed For Managing Work – Transformation Is Coming.

Despite our collective understanding that email is flawed as a workflow management tool, we are firmly entrenched in its use.  What is needed is a generic solution that mirrors the simplicity and flexibility of email but adds better workflow tracking and management reporting features.

As I wrote in my earlier post, Email vs. social networking in your workplace, I would separate the term “email” as a messaging system/infrastructure (as defined by RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) from “email” as email client software for reading/sending/managing email messages, implementing only a specific use model, usually dated 10-15 years ago. And so when it comes to the email clients I really agree with the article, most email clients are outdated and have not kept up with the workflow management requirements so it is obvious that new generation email management apps need to be developed.

Email as the messaging infrastructure is actually quite solid in my opinion and can be leveraged quite successfully by those new generation tools. I am probably quite “old school” but I love email. BTW, see the comment for that article about the recent Skype outage, could this have ever happened to email and paralyze millions communication channels? What I believe is that simple and open wins and email is simple and based on open standards so there could simply be a better email client that is also designed to enhance the workflow management.

I have to admit though that I am quite biased in my opinion because we’re working on a tool like that ourselves. We simply want to leverage the email based collaboration model that most organizations use today (many of which are MS Outlook based). I think most organizations have chosen to use email for a good reason (flexibility, simplicity, ubiquity, you name it …), so lets just go with what already seems natural and enhance the experience.

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:

  1. 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.
  2. 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:

http://blog.acornsys.com/The-Acorn-Blog/bid/47380/Why-is-Time-Driven-Activity-Based-Costing-Such-a-Game-Changer

http://www.entrepreneur.com/tradejournals/article/168435559.html

 


I have been quite a fan of agile methodologies, I see clearly the benefits of developing products in iterations and taking healthy customer feedback regularly. All in all this really helps you to focus on the product value.

But there is another aspect to these methodologies, which bothers me. Lets take SCRUM for example, and its morning stand up meetings. The more I hear about these, how much pressure they put on team members, how focused they are on making people deliver on their stories ASAP, the less I like them. It feels the main goal here is elevating stress level and pressuring people. The “war room”, the battle culture, everyday. Do you like playing rugby at your workplace? Well, what do you want from a methodology with such a name:

The word “scrummage” is a modification of “scrimmage” (the form of the word previously used in rugby and still used in American and Canadian football), which in turn derives from or is a reflex of “skirmish“. The term was used in the laws of rugby football for a long time before being permanently contracted to just “scrum”.

I can see how this “war room” could be very useful in certain critical short-term situations where you need to focus and deliver something quickly but I suspect that when used all the time this constant pressure will affect productivity negatively. People will get burnt out and start hating their jobs. I hear SCRUM is becoming more popular among all kinds of teams (marketing, sales), not just development. Is this a new way of the corporate management achieving greater productivity? As though I hear them say, “You guys wanted agile, we’ll give you agile. We’re doing SCRUM morning stand-up meeting now!”

To me it smells once again like the old “command-and-control” style of management. Get everyone in one room, make sure they are working on their “sh$t”. And do it everyday as they are so stupid they won’t figure out on their own what needs to be done without this morning “whip”.

I have a feeling this SCRUM thing is killing initiative and creativity in teams. Management in the 21st century is about productivity, but with the focus on productivity of individual knowledge workers, so de-centralization is the word! The workers are smart enough to figure out what and especially how things need to be done. Are these stand-up morning meetings helping them be more productive?

Just hear what Peter Drucker, the guy who invented management, said in 1999:

“The most important, and indeed the truly unique, contribution of management in the 20th Century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st Century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”

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?

Part of the new Yoxel PCM build is integration with Google Calendar.

For email accounts hosted at GMail Yoxel PCM can now automatically import calendar events to block out those time slots from its work-hours calendar. The work-hours calendar is used to plan/estimate work on tasks.