Unlocking the cloud
Posted by Rudolf Melik in Enterprise Software, project management, project workforce management on June 16th, 2009
Here is an interesting perspective on cloud computing from the Economist. The article contends that customers subscribing to an on-demand service should be wary of data ownership and the data migration difficulties they will face when moving their data from one SaaS (software as a service) vendor to another. The author positions open source as a liberating technology and sees cloud computing as new attempt by software vendors to lock-in customers.
This is the first time I ever heard anyone argue against cloud computing. To tout on-premise open source systems as liberating technologies and to call SaaS and cloud computing as a step back is simply out of touch with what is occurring in the marketplace. At the heart of its argument against cloud computing is the lack of standards for moving data from one service provider to another. However, the same can be said for migrating data from one on-premise solution to another, whether open-source or not. For example, have you ever tried moving data from an Oracle application into a Microsoft or SAP application? No common standards exist today that would automate the migration of any form of enterprise data from one solution provider to another.
However, the process of importing data has become a relatively painless, inexpensive and a low risk activity for most forms of data. Data in most modern enterprise applications (on-premise or on-demand) is represented in XML or can easily be exported to XML, now a ubiquitous standard for data representation and data exchange. Using XML, just about every cloud service provider (and even legacy application providers) have the tools and the expertise to migrate data from the customer’s current formats and systems. There may of course be some minor challenges to overcome and the migration may require investment in a few days of consulting services but I do not at all see how data migration results in vendor lock-in.
One thing that customers need to make sure of is data ownership. Tenrox project management software and workforce management customers own their data, whether they are on-demand or on-premise. This assures our customers that they are totally free to move to another service provider.
Cloud computing has tremendous benefits for the customer. The service provider takes care of all the details of software maintenance, bug fixing, data backups, 24/7 availability, 99.9% up time, data security audits and certifications, bandwidth, worldwide access, and much more. This frees internal IT to spend time on more strategic work such as IT project portfolio and resource optimizations, data analysis, portal/report development, and activities that are directly related to the company’s core business.
The Next Game-Changers
Posted by Rudolf Melik in Globalization, The Global Economy on June 11th, 2009
Nice article by Morningstar on how technology and market forces are making fundamental changes in the competitive landscape. Companies whose previous market dominance and position were virtually unassailable have now become also-ran businesses experiencing a rapid decline in revenue and, specially, profits.
There is also a good non-techie explanation of Cloud Computing. Here is an excerpt:
Consider “cloud computing” (which is sometimes called “software as a service”). Basically, instead of having all your software and files installed on your computer, in a cloud computing world, you would just fire up a Web browser and use services provided remotely from central locations. In the current way of doing things, I buy Microsoft Word, install it on my machine, use it, and store my files on my local hard drive. But on the bleeding edge of technology, I could just fire up a Web browser, visit the Web site of a word processing service (such as the current Google Docs), and save my documents on the service’s central computers. It’s cheaper, and the documents are automatically backed up and available from anywhere.
Allow me a short analogy using electricity. Think of how the world would look if each of us had our personal electricity generator in our backyards. Although silly and inefficient, this is essentially what we have with computers today. Eventually, it looks as though the computing world will move to the electricity model, where power is generated efficiently at a handful of central locations and then distributed via a robust transmission system.
Another emerging example of this trend comes from console gaming. A new firm named OnLive will soon be offering a service that–according to early reviews–will offer games comparable to what is available today from Microsoft’s Xbox or Sony’s PlayStation. But with OnLive, there is no big box under the television or physical games required, just a controller and a simple device that connects to the Internet.
…
Cloud computing is perhaps the most revolutionary trend in this article, as opposed to the other trends that are more evolutionary. Simply put, software is no longer married to hardware. Or, just think of it as the trend toward having the majority of computing power no longer distributed on millions of desktop boxes, but rather provided by central servers in thousands of locations and distributed via the Internet.
Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences
Posted by Rudolf Melik in Project-Based Solutions, project management on June 3rd, 2009
Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.
Applying Occam’s rule to product design and development could go something like this:
- Design features that are simple to use
- Provide just one way of performing a function
- Don’t oversimplify
1) Design features that are simple to use
If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:
- There is a tendency to try and build an all in one comprehensive solution Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie.
- Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage
I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.
- Iterative reviews focused on what is missing complicate product design After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.
2) Provide just one way of performing a function
As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.
3) Don’t oversimplify
This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications. We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.
However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.
In a future blog, I will apply Occam’s Razor principle to making IT investments.
A Primer on Just-in-Time Resourcing
Posted by Rudolf Melik in Professional Services Automation, project management, project workforce management on May 25th, 2009
A Primer on Just-in-Time ResourcingSM, Enabling the Concept of Just-in-Time Resourcing (JITR) with Project Workforce Management is a white paper I co-wrote with Randy Mysliviec CEO of RTM Consulting. Just-in-Time Resourcing (JITR) can offer significant advantages and immediate benefits to professional services agencies, consulting companies and other expanding technology firms needing improved resource planning. “Stop gap” and other measures can compound the problems in handling large scale fluctuations in labor sourcing and management. Find out how JITR addresses the need for optimal resource supply for growing businesses, and how to enable JITR through project workforce management software.
You can register and download it here.
I have to finish this today
Posted by Rudolf Melik in project workforce management on May 19th, 2009
What follows is a memo I sent to our team a few days ago.
After getting several bids and checking references, we hired a company (owned by a guy called Tony) to do the landscaping for our home. It was a fairly big project since the unfinished backyard was not level, was full of dirt and stone. In less than 14 days Tony transformed our yard from a vacant lot into a very nice looking backyard. From past experience, I would have expected this project to take several months. I guess we picked the right person for the job!
He worked side by side with the workers he had hired. Everyone who saw Tony working including our neighbors were amazed. To quote my neighbor “When the owner of the business gets down on his knees, digs, cuts, installs, and works right along with his team … wow!”
He started every single day at 6:30 am and would work until 8/9 pm with very few breaks. He is so intense during work that I would hesitate to interrupt him. He was “in the zone”. It seemed that every single day he had decided (and probably visualized), even before the day had started, what he would finish for that day. Come hell or high water he was going to accomplish that one day goal, and by gosh he did.
When we got a chance to speak, he explained to me how the small bulldozer he uses is 15K more expensive than what other people in the industry use but he chose to invest in it because it allows him to work even when it rains (he does not get stuck in the mud like the others do). Last night we came home after going to the movies with the family, as we approached our home around 9:30 pm I see the whole yard is lit. As we got closer I see his entire crew was still working! He explained to me that they had to finish laying the grass and he uses projectors so he can work after dark.
So much of what he does and how he does things reminds me of us, in the first five years of Tenrox when absolutely no obstacle was too big. We had the same instinct, raw desire, and intensity he has today. Just seeing how he works has re-energized me!
The World economy in general and the United States specifically have experienced a significant almost unprecedented slowdown and huge, real losses. Many very well known companies were wiped out or had to resort to substantial layoffs to try to adjust to the new market forces of slower growth and lack of credit.
I hope more of you will remember Tony when you come to work tomorrow. Focus on results, have a specific achievable target for every single day you are present at work, get into the zone, and finish what you started instead of jumping from task to task, accomplishing very little. This kind of attitude will ensure that we (Tenrox) remain unbeatable. Who can compete with that!?
Work as if you have to.
It is surprising what a man can do when he has to, and how little most men will do when they don’t have to.
- Walter Linn
Project Management War Room, One Year Later
Posted by Rudolf Melik in project workforce management on May 14th, 2009
About a year ago, during a customer visit I noticed an interesting combination of hi-tech/low-tech project management and planning techniques which I later called the Project Management War Room and wrote about here. We implemented our own versions of this war room for our R&D and Professional Services (PS) teams. The results have been something to write more about!
After nine months of trying this out ourselves, I can report that both the R&D and PS war rooms have been highly effective. Both teams hold a 30 to 45 minute weekly project status meeting in the war room. I attend some of them just to keep in touch but read the minutes of their weekly meetings pretty regularly. Since the creation of the war rooms I have observed a noticeable improvement in project execution and a significant increase in our team performance consistency. It seems that a wall full of visual information, key project dates/timelines on the wall, yellow or red flags if projects are late, bug stats, weekly action items per project manager on flip charts … all in one room makes people more accountable and responsive for their projects and deliverables.
Here are a few best practices we have come up with so far:
- Keep the information on the walls to the absolute minimum to reduce overhead work and to make sure the wall gets updated regularly. We write project/feature name, the developer/consultant who owns it, the expected completion date, and the status (shown using a color and two to three other pieces of information such as delivery date, number of bugs open for that module). The key is to use colors, large normal and bold characters, and simple timelines to convey the bottom summary status. More detailed information is maintained in computer files/databases. We use a projector and drill into the detailed by looking at project and workforce reports when we need to. However, 99% of the time, the information on the walls is all we need to focus on and discuss during our war room meetings.
- A new item we have added of late is we write the original estimate for the project or feature and current spend level. This has also helped us quickly see which parts of a project are going off plan. I have included a sample of the project boxes we have on our R&D wall.
The service team was tracking a lot more detail on their wall. After attending the last meeting I could see how their version was not working as well as that of R&D. I could not tell, at a glance, where the issues are and what action is being taken. There was too much information to go over in 30 seconds which is my maximum attention span for such things. I asked the service team managers to take a good hard look at how R&D is doing it and to adopt more of their keep it simple approach.
This simple combination of good old fashioned paper printouts, sticky notes and timelines on the wall, flip charts to look at the big picture, and a computer/projector so we can drill into the project reports is working very well for us. The visual impact of the war room, the intensity it has brought to our project teams and the performance improvements we have gained is incredible.
Investing in project management software and the hair loss doctor
Posted by Rudolf Melik in Enterprise Software on April 6th, 2009
As I got the idea for this blog I thought a small cartoon strip would help convey the message much more clearly. My artistic skills however are sorely lacking and the Tenrox Web team is way too busy for me to dare ask for their help to develop a cartoon, for a blog no less.
So as everyone does these days I launched a new window and searched for “make a cartoon”. The second entry ToonDoo – The Cartoon Strip Creator – Create, Publish, Share, Discuss! sounded interesting, relevant. Amazingly enough, this is a totally Web based easy to use cartoon making site. It took me less than 10 minutes to make the strip below using the most basic elements offered by the site. Of course, my children (11 and 
have already far exceeded what I was able to do. They quickly learned how to design their own avatars and have created some pretty amazing cartoon strips.
Back to the original subject for this blog, we live in very interesting times. In good economic times a rising tide lifts all boats. On the other hand, as we have seen, a severe economic downturn exposes the true state of all structurally flawed organizations, and incompetent leadership. What amazes me our headlines like this:
Company X, the leading provider of workforce management software, cuts jobs. A cut of about 8% of its global workforce as of January 9, 2009.
Y, the leading provider of on-demand project management software, announced its third round of layoffs. The company laid off 25% of its workforce in this round.
These same project management and workforce management “optimization” companies are advertising their expertise and pushing their solutions as the best software tools one can invest in. If they cannot plan and manage their own projects and workforce properly how can they claim to help anyone manage their resources any better? This is the definition of hypocracy.
Unlike many of our competitors who have suffered through multiple layoffs. Tenrox has cautiously hired new team members. So far, we have continued to grow and have remained profitable during this severe economic downturn. I think it is partly because we practice what we preach. We use our own software to manage our workforce, plan our projects and pipeline based on the same best practices we share with our customers. We use various trusted technology and marketing partners to handle peaks in our workload. We do not over-hire when times are good and then engage in mass layoffs when times are bad … As a result, we have a stable, loyal and enthusiatic team who actually loves what they do … We will do our absolute best to keep it this way.
The Unbundling of the Corporation
Posted by Rudolf Melik in Globalization on March 30th, 2009
Here is an interesting article from the New York Times on the impact the credit crisis is having on corporate models.
Part of the article discusses the transformation of corporate structures:
- Let’s try a different lens. How have past crises shaped management thinking and strategy? Innovation in management, after all, is adaptive. Management is not a science, like physics, with immutable laws and testable theories. Instead, management, at its best, is an intelligent response to outside forces, often disruptive ones.
- Times of severe economic duress, management experts say, can serve to sharply accelerate trends already under way.
- The technologies made it possible to monitor and coordinate business operations as never before. And the Depression made it imperative for managers to achieve efficient economies of scale to tap national markets, ensuring corporate survival amid a downward spiral in total demand.
- A modern version of that kind of technology-aided shift in management practice and corporate organization could be in the offing, says John Hagel III, the co-director of the Deloitte Center for Edge Innovation, a research arm of the consulting firm.
- The sharp downturn, according to Mr. Hagel, will force companies to go beyond simple cost-cutting to take a hard look at the economics of their businesses. Most companies, he says, are actually bundles of three different businesses: infrastructure management, product and service development and commercialization, and customer relations.
- The current crisis, Mr. Hagel says, opens the door to “an unbundling of the corporation” to achieve greater efficiency and profitability. The trend, he notes, is already exemplified by specialist companies that focus on particular infrastructure fields. In logistics, Mr. Hagel says, many companies farm out those chores to Federal Express and UPS; in call centers, he points to Convergys; and in contract manufacturing, to Flextronics.
- .. look like an Internet-era rerun of the corporate transformation of the 1930s and ’40s. “We’re facing the potential to have that play out again — this time with digital infrastructures that allow companies to organize and manage their activities in new ways”
The un-boxing of the organization is a trend I alluded to in my Ten Predictions for Project Management Trends in 2009 (see #8 the rise of the project workforce).
The article also mentions how large companies are creating smaller almost independent organizations within the larger entity and smaller teams within their product and service development divisions (for example) because they have learned that innovation and progress is far more likely to occur with such small teams. A trend I also see over and over in every project I have been involved with in my entire career.
The second part of the article discusses how the economic crisis is redefining the role corporations have to play now that government has been forced to get so intimately involved in their oversight and bailout:
TODAY, the pendulum is swinging back to a model in which corporations will be regarded more as social organizations, whose obligations extend well beyond Wall Street, according to Rakesh Khurana, a professor at Harvard Business School.
It is truly remarkable how important transparency, accountability, and social responsibility have become. I would even venture to say that these metrics are becoming as important as profits and growth in assessing a company’s value and whether it is deemed to be a dependable partner or a worthwhile investment.
Comparing observed behavior to project management actuals
Posted by Rudolf Melik in project workforce management on March 20th, 2009
Coming back from a vacation is never easy. I have been trying to finish this post for the last week and time was just in short supply. Anyhow, I have finally caught up and gotten back to normal. In the last post I decided to embark on an experiment to examine what if any differences there would be between what one observes people doing at work versus what they report using our project management software, weekly timesheets, and status reports.
I sampled people in various departments at Tenrox twice a week as discreetly as I could in order not to disturb them or attract any attention and change behavior. I employed the following rules during my observations:
- Observe 2 different people in each department and record what they are doing at that moment; I called each of these observations a sample
- Exclude all managers and executives from the experiment; except for R&D managers because I wanted to measure how much they actually spend on various tasks, specially on meetings
- Take 2 samples per day; twice per week; for 8 weeks
- The samples must be taken randomly at different times of the day and of different people
After the sampling was complete I compared the approved timesheets and status reports to the observed activity. Here is a summary of my observations:
Table 1 – Percentage of Time Working (includes meetings)
| Based on Observation | Based on Timesheet | |
| Account executives | 88% | 100% |
| Inside sales | 81% | 100% |
| Marketing | 88% | 100% |
| R&D team members | 94% | 100% |
| R&D management/project managers | 100% | 100% |
| Support | 94% | 100% |
| Professional Services | 100% | 100% |
Table 2 – Percentage of Time in Meetings
| Based on Observation | Based on Timesheet | |
| Account executives | 13% | 0% |
| Inside sales | 6% | 0% |
| Marketing | 6% | 2% |
| R&D team members | 13% | 8% |
| R&D management/project managers | 63% | 45% |
| Support | 6% | 0% |
| Professional Services | 6% | 5% |
In my observations I considered that the person was “not working” when they were talking about non-work related topics, or just taking a break (such as a smoking break, coffee break etc.). Also, to be fair, for those specific individuals who took longer “breaks” during the day, I took a note and checked to see if they left later that day to make up for it. If this was not the case then “percentage worked” reflects the deficit.
Well! The experiment was much harder to run and took a lot more time to perform than I had expected. Here is what I learned and the action items:
1) Broken Breakdown Structure
In our timesheet system we have the concept of a Task and a WorkType: Task = Project + WorkType
WorkType is used to define the type of work one does; and it can apply to any project. For example “Design” is a work type, “ABC Design” is a task you report time against when you are doing design work for project ABC.
One of my first surprises was that we had more than 6 different “Meeting” work types in the system such as “General Meeting”, “Meeting”, “PS Meeting”, “R&D Meeting”, “Marketing Meetings”. With each of these work types associated to one or more team-specific and customer-specific projects.
I had to generate time reports that included all of these work types to be able to measure how much time is being reported as time spent in meetings.
We definitely do not need 6 meeting work types. First action item is to clean this up so we have clear and consistent work types used by all teams to report meeting time in their teams and for any projects.
2) What’s a Meeting?
We have to make sure everyone has the same definition of a meeting. For example, R&D managers and sales team have a lot of 1 to 1 or small group meetings in their offices. This time was not reported as meeting time which is fine as long as we do so consistently. Looking at the samples versus what is reported in timesheets, and after speaking to a few people, I can see that this is not the case right now. Also some people marked some training sessions as meeting time whereas others recorded this time against a training work type.
3) Now let’s look at Table 1 results and my analysis of the differences:
- Our account executives do take time during the day to socialize with each other and other team members. However they work hard and I know they are responsive to customers even when they are called upon outside business hours. So the observations while valid are not a cause for concern.
- Our inside sales team also does some socializing and participates in meetings but their timesheets report no such details. However, they have a pretty tough job. Making hundreds of calls per week following up on Web leads and other marketing activities. I hear them sometimes, they show remarkable patience and they actually care about their work so the breaks are very much needed to let some steam out.
- Marketing which includes our Web team definitely has room for improvement. The observations confirmed what I already suspected. This team can and should do better than it does now. Web team members have to feel more intensity and a sense of urgency in their day-to-day deliverables. The experiment has actually provided me with new insight on this team.
- R&D team members require a lot of freedom so they can be creative, intense, and excited about what they do. Therefore, given the great success of the last two releases, the occasional walking, chatting and longer breaks are not a cause for concern.
- I am willing to cut the Support team some slack too. As part of this experiment, I decided not to just let one number lead me to any specific conclusion. Our 90 days plus accounts receivable (A/R) as a percentage of total receivables is near an all time low, our blocking support issues and SLA (service level agreement) compliance were well under control, so the team is more than justified in taking a break here and there. Of course, this would have been a red flag if the other metrics came in on the critical side. Definitely I will sample this group again if and when I see our A/R creeping up or an increase in SLA-compliance related issues.
4) Let’s look at Table 2 results and my analysis of the differences:
- The account executives report time at a very high level; simply reporting hours worked against a task called “Sales Activities” so you cannot tell how much time was spent on calls, in meetings or anything else. I do not think we need more detailed time reporting for this team especially since most of the team is comprised of veterans.
- Our inside sales team also reports time at a high level. I think this should change. We need to cross reference their timesheets with phone logs, qualified lead counts and lead quality. Although I understand they need to take some breaks from time to time, I think more detailed time reporting will help us ensure this team stays on top of its game and reassess what they spend time on if and when our lead count or quality goes through a rough period.
- Marketing which includes our Web team was inconsistent in their timesheet reports. Some people are reporting time spent in meetings and some are not, some are providing more detailed time reporting against specific tasks and some are not. I will meet with the head of that team to discuss these inconsistencies and agree on what the reports should include. I think the marketing team, specially the Web team, should provide a more accurate picture of what tasks and projects they are working on (for example: search engine optimization, trade show preparation, Web site design, PR, etc.). Right now it is a mixed bag.
- In comparing what was observed versus what was reported, R&D team members were remarkably accurate in reporting how much time they spent in meetings. The percentage spent on meetings was higher than I expected but this is probably because the R&D team is gearing up to work on the next major release so specification meetings and reviews are likely to be more frequent and longer.
- R&D management/project managers are spending a lot of time in meetings. The discrepancies in the percentage spent in meetings come from higher level executives who are not providing detailed reporting of what they are spending time on. If I take the higher level managers out then what was observed is in the range of what is being reported. Still, I think perhaps too much time is being spent in larger group meetings by high level managers. I prefer more of smaller, shorter, targeted group meetings to fewer large meetings, even for a major release than what I observed.
- Support team was a mixed bag as well. Those on the on-demand side are not reporting at the project level or any details of what they do. On the other hand, core application support team who is spending time with customers is providing very detailed time reporting. This should be addressed as we need to track costs of our on-demand initiatives and any time our on-demand team spends with customers.
Summary and Closing Remarks
This was quite a valuable experiment. Comparing observations to what is being reported to actual results has provided me with new actionable information that will help us improve how we run the various teams and our tracking systems.
The conclusion I draw from this exercise is no single data point can help management run their business well. You gain insight by looking at all of them combined: project management reports, observing people, walking and talking to people, customer surveys, and looking at the company results. That is the only way you can spot potential problems and prevent them or identify best practices and promote them to other parts of the company.
I would highly recommend this exercise for any high level executive or line of business manager. These types of activities help us get closer to the action, get the real facts; not just see things through rose colored glasses, and better understand the inner workings of our teams.
Sampling as a workforce productivity measurement tool?
Posted by Rudolf Melik in project workforce management on February 24th, 2009
If I asked you which one is more accurate what would you say?
1) 4 weeks of approved timesheets showing what your project teams have been working on
or
2) you get up and walk around twice a day and only two days a week, at different times of the day and different days of the week, to observe what randomly chosen people from different groups are working on. As much as possible try not to interrupt people or look too “suspicious” as this would change the results. What you are trying to do is observe without interference. Take notes and record your data each time. After 4 weeks you have some sample data.
At the end of the 4 week period, compare your sample measurements to the timesheets, and status reports you have for that same period.
I ran this expirement for 4 weeks by observing the following departments in our company: sales, support, R&D and service teams. The results were quite surprising. I will share the results with you in a future blog. In the mean time, I look forward to getting your feedback on which option you think is a more accurate measurement of what people are working on.