Category: timesheet

Home timesheet ()

Can we be beta testers of your next version?

I get this request on a semi-regular basis and given the work I’ve done with Microsoft, Oracle and other technical partners over the years, I’ve been involved in a number of early-release software programs.  So, let’s talk about what people mean when they talk about Beta Test Programs.  The first thing to know is that the perspectives of what the vendor is hoping for and wants are often different than what the users want.

First of all, what’s a beta test and who came up with that clever name?

Beta is the second letter in the latin alphabet with “alpha” being the first.  Programmers, clever as we are, used the terms to refer to first and second levels of testing.  Alpha testing is supposed to be the kind of testing done at the programmer’s station or at worst within the development department prior to release.  Beta testing was supposed to be testing at the user level where real production data was run through the program.

In an enterprise application, neither of these terms is particularly relevant.  Quality Assurance (QA) of software is a spectrum of testing that ends up with a product in the hands of an end user.  The numbers of levels of testing is often unique to the particular situation.

What does the software publisher hope for from a beta tester?

Ideally, a software publisher would give a release candidate of software to a client and they would use it in full production in parallel with their own operations for a period of time and therein lies a problem.  If we’re talking about an application that would be used for an hour or so a day, such testing sounds just fine.  If we’re talking about an enterprise application that is used across the user-based, then such testing is almost impossible.  The very people who the publisher would need to do the testing already have full-time jobs.  They are processing all the enterprise data that comes in every day or every week and generating reports, activating processes or exporting and importing data just to keep up.  To really run data through the new version would mean essentially duplicating that entire exercise.

Our TimeControl system is a timesheet. Surely we could get people to duplicate their work for a timesheet?  You’d think so, right?  Our experience is that it’s close to impossible.  Perhaps if our product was a video game we would have a chance but to ask people to sit down to their timesheet once is a big enough challenge.  Asking them to do it twice, even for a short number of weeks is almost always too much.  Then once the data would be in, we’d have to have the supervisors, administrators and project managers duplicate their effort.  It is not as easy as it sounds.

To make a beta test work, we need to not only duplicate the effort of entering the data, we need to have sufficient commitment from management for the extra time and effort and a commitment to go through the process of managing two timesheets for a time.  The response from management is almost always negative.

Of course, there’s no point in having the new timesheet if you’re not going to try out the new features so not only does the publisher need the existing functionality reviewed, but a real effort on the new functionality including configuring, updating any relevant processes and more.  Again, that’s a big ask.

What is the user hoping for by being a beta tester?

They’re aligned right?


Mostly beta testers are interested in peeking at just-finished functionality to give it a try and see if it will fulfill their business requirements now.  Almost everyone who contacts us to ask if they can be a beta tester isn’t interested in using the software in parallel with the current version.  They just want to start using it with the new functionality.  We’ve actually tried this in the past and found it’s terribly unsuccessful.  The expectations of these users is that the software is fully functional and stable.  The antithesis of a version that needs testing.

So they’re not so interested in just reporting issues to be resolved, they have an expectation that the technical support team will be instantly responding with an upgrade to their “beta” version because despite all our recommendations, they’re actually using it in production.  In the end, the delays of supporting these people delays the release of the production version more than if we’d never had the beta testers at all.

I can remember working on one of the early release versions of Microsoft Project and having users horrified that when the early release version was replaced by the actual version, there was no path to upgrade the data from beta to production.  There was outrage from the users that the work done in the “beta” versions could be saved and updated to the actual version despite warning after warning, the absence of any promise that this would actually be possible and the early release agreement itself.  Users had put production data into the release candidate, not in parallel but instead of the current product.  Mostly they had to redo that work once the new version was released.  So they weren’t really interested in beta testing at all.  They just wanted a fully functional, working copy of the next release before anyone else.

Who should and shouldn’t be a beta tester?

On a regular basis we get requests from prospective users offering to be a beta tester.  They’ve not read this article of course.  They just want a feature that isn’t yet available but might be soon.  They may be very smart.  They may be very experienced but they’re not experienced with our product.  They’re still prospective customers.  Prospective clients are a terrible choice as a beta tester.

Ideally, if a client really is willing to assist with the QA process, the testers will first have the capacity to run an enterprise product in parallel with real data and sufficient resources to manage the entire enterprise process including data entry, approval, onboarding, reporting, exporting etc. over a number of periods.

We almost never have clients who are willing to do this and, when we do, it’s almost always because of a particular environment where our technical staff are already embedded or working on some functionality specifically for that client.

So, if I can’t beta test, what can I do?

There are so many ways clients can be supportive of the evolution of the software.

magnifyingglass.jpgFirstly, they can communicate their desires for features in upcoming versions.  When this happens and the desires match up with features already being considered, we will often include dialog from the client as part of the design process.  Then we might even give an advance look at how the function will work or, in some cases, weave that function into a specialized version of our product for the client to work with.

Next, clients can be proactive in using the new version in a test or staging environment in a timely fashion as soon as it is available.  Early feedback from clients is expected and welcomed and, if there is some issue that pops up at that time, it’s much easier to talk about from the calm staging situation than to say that you’ve just upgraded your production environment with the new version and the whole company has stopped.

More important than all of that is something that our own staff have to be conscious of as much as our clients and prospective clients.  Instead of focusing on the availability of a feature, work with the software vendor on your business problem.  We recently had this very situation in working with a large software company.  We needed help on a feature that is clearly not working as documented.  I’ll spare you the long details but the final result was “that feature isn’t going to work like that”.  It wasn’t helpful.  But in debriefing with my own staff, I discovered that we’d never told the software vendor what we really needed.  Instead of talking about the business problem of “I need to get timesheet actuals to your product in the area where timesheet actuals are stored”, we said “this feature, documented on page 465 isn’t working and either fix it or tell me how to code around it.”  We fell victim to the very thing we ask of our clients “Please tell me your business problem before I start describing the solution”

So try thinking about what you need to accomplish in terms of a business solution rather than the in terms of the feature you hope will fix that problem in some way.

If you’re a hammer, everything looks like a nail

hammer-and-screw_300x199.jpgI have an expression that my staff and clients have heard me use often.  It’s a favorite of mine.  “If you are a hammer, then everything looks like a nail.”  It’s a paraphrase I know and as I was writing this article, I thought it behooved me to look up the source.  It wasn’t much of a surprise that the author was someone who I read a lot of a long time ago, Abraham Maslow.  One of his most popular theories was Maslow’s Hierarchy of Needs; something I have used in management consulting for years but discussing that topic will have to wait for another article on another day.

My focus today is hitting everything as though you are a hammer because it looks just like a nail to you.  Maslow’s actual quote was: “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” (The Psychology of Science, p15, 1966, Abraham Maslow)

It is.

I have a staff of programmers who are among the best in the industry.  It is a small core team of people who work on our enterprise timesheet system TimeControl and they are very, very good.  Our small team services some of the largest and most complex project management and cost control environments in the world.  We work for those in the public and private sectors, in defense, in aerospace, in research and development, in new product development, in the utilities sector and more.

For those who have read this column often you know that I espouse the belief that if you want to create a solution, you must first listen to the problem and many of those articles have come from my thinking in preparation for internal meetings when I coach our consulting and development staff on how we can best serve our clients.

Yet, our development staff are finely tuned developers and, guess what, every time someone asks them for something, their minds default to thinking of how they could develop it.  It is something they are used to being on guard for and for the most part, they catch themselves before the client even knows it.

We ask them to think of not just how to do a thing but whether we should do it at all.  When they think of how they could easily program something, we have them think first of how they will justify that the development is the best way to solve that problem for the client.  Moreover, we ask our team to think of not just what it will take them to develop it but what the total cost of ownership of that development will be including lifelong support of that feature, managing the impact of that new feature on hundreds of thousands of other users and how we will need to test and quality assure that feature not just today but for years to come.

This blind spot that Maslow captured so beautifully in a single sentence isn’t reserved to developers.  It’s something that I encounter almost every day.

We sell a flexible timesheet system designed to fulfill the requirements of multiple departments simultaneously.  I have seen numerous deployments where the project team were involved in the early stages of deployment and then brought in the Finance team for their input.  To what should be no one’s surprise, the Finance group look at how the Project team configured the timesheet and immediately determined that it was completely wrong.  Payroll looks at a timesheet from the perspective how do I get the payroll out.  Billing looks at it from a perspective of how do I get my invoices published.  R&D wants to know if all of their research and development expenditures will be accounted for and, of course, project management wants to know if the timesheet will deliver the actuals for their planned activities back to the project management system.

By far the easiest sell would be to never get these people into a room.  Instead, send the payroll timesheet salesman to the payroll people and make their sale there.  Send the time and billing timesheet salesman to the billing people and make their sale there.  Send the project management software people to the project people and show the timesheet already there and make their own sale there.

Sadly this is too often the case.

The result is the deployment of multiple pieces of software all doing something similar.

Several years ago, I spoke with a public sector municipal CIO.

“We have too many timesheets is my problem,” he said.  “I’m reluctant to look at one more.”

“How many do you have?” I asked.

The CIO looked around the room to be sure we were not being listened to.

“Nine,” he said.

There was a long pause.  He knew we were suggesting that our product could fulfill many of the requirements of those nine systems.

“I know we’ll never get to one,” he said, “but anything less than nine would be very good for us.”

In the end, I think they got down to 4 a couple of years after deployment our TimeControl.  It’s not that TimeControl was the only solution.  In fact, there were obviously many solutions to choose from.  It was finding the less obvious requirement of flexibility that delivered the value to the whole organization.

Sometimes just knowing you’re a hammer can have you take pause and look twice.  Is that a nail?  Let me look again.

How Black Hat thinking helps resource management

I admit it.  I’m a black-hat thinker.  I think I always have been but many years ago, my first partner gave me a copy of Edward de Bono’s “Six Thinking Hats”.  sixthinkinghats.jpgThe book is tiny but the impact was profound.  De Bono was interested in how people think and in how people could train themselves to think more creatively; more laterally.  There’s no one hat that’s perfect of the six, each has its own attraction and its own power but of them all, being a contrary thinker as you would be while wearing the black hat has always been my favorite.  Someone says “that’s impossible” and I reflexively say “I don’t think so” but then have to defend my position and this makes me think much more creatively.  If you’re a regular reader of my column, you’ve no doubt seen this flavor of analysis in the way I approach project management and managing enterprise project management systems.

Sometimes, attacking our resource capacity challenge with counterintuitive responses can reap huge rewards.  Here are a couple of examples of how wearing the black hat might help us if we are struggling with the common issue of having insufficient resources:

Don’t manage everyone

I’ve worked my entire career implementing enterprise project and enterprise timesheet systems and while many aspects of each deployment are unique, one thing is universal: management feels compelled to manage the resources of the entire enterprise.  If you’d like to get a room full of managers salivating over an enterprise project resource management system, tell them they can see the work and plans of each and every individual.  Showing management how you can drill down from the project portfolio level all the way to someone’s daily to-do list elicits a visceral response.


This may not be the most effective thing to do.  Over the years I’ve found that organizations that try to centrally manage resource levelling to the individual level end up tremendously frustrated or, worse, terribly ineffective.  When you dissect the challenge the organization is facing it is apparent why it is not easy.  Enterprise level analysis of each and every person generates so much management effort that we’d almost need a manager per person to follow people around to make sure they do what we were hoping they’d do.

There is a counter-intuitive cheat for resource levelling that is almost always tremendously effective.

Don’t manage everyone.  Instead.  Pick the small number of absolutely key people who have that unique combination of skills and knowledge that makes them critical to the most important projects and centralize the management only of them.  Now, when I’m talking about a small number, I don’t mean 20% of the team.  For a 200 person department, I’m talking about 5-7 people.

A couple of very interesting things happen:  First, the project managers who had been hoarding these key resources for their own projects will now only get them for the time they need.  That makes these key people suddenly available for other projects.  Surprise, surprise, that makes the whole organization more effective.  Secondly, we don’t adopt an incredible burden of managing everyone else down to the minute.  Instead, we let department or project managers assign those people however they do.  This also makes us more effective.

Smaller teams

“We’re going to need a lot more people,” I’m often told.  “No, you don’t,” is my reactive response.  But do you?  I have been on project after project where we were up against a resource challenge and instead of increasing team size, we reduced it.  It’s counterintuitive but I’ve found over the years that there is a tremendous overhead for certain kinds of project such as software development when the team is large.  A development team of four people can be twice as fast as eight or four to five times as fast as twenty people.

That doesn’t seem to make sense, I know.

But, putting four key people into a co-located environment and removing all distractions can produce startling levels of effectiveness.  I’ve done this myself on a number of occasions and there is no formula for it.  Each type of project and industry will have its own rules for this but my message is that you shouldn’t automatically assume that more people means faster development.

So, when confronting demands for making the team larger, consider at least, the possibility of going the other way.  You might be startled as I was at first, that this can often deliver big benefits in throughput.

Don’t finish everything

If you work in a strongly Agile software development environment then you might think like this already but for many project managers we tend to fall into the pitfall of assuming the scope is immutable.  “There’s nothing we can do about reducing the scope.  It’s a given,” I’m told.  “I doubt that’s true,” I automatically respond.  In fact, if you bring some Agile thinking to your project’s scope you might find your client is inclined to participate.  I have worked with several project managers who were facing projects where they worried they would have long delays if they couldn’t get many more resources.  In these situations where I encouraged a discussion with the client, it was common to get an unexpected response.  “Here’s where we’re at,” I would explain to the client.  “If you want all of what you originally described, it’s going to take a number of months and we’re not even certain of how many.”  At this point, the feeling of hopelessness of the client would be palpable.  “But,” I would continue, “If you could take what we are describing here,” we could deliver *that* next week.”  Now there is a look of hope with the client.

A couple of interesting things happen here.  First of all, the client gets the partially completed product into production.  And, it should be no surprise, once they have it in production, they think of even more or different things they’d like done to it.  Perhaps the original idea will never come to fruition because the client themselves pushes the project into a different direction.  It’s a very Agile concept but Agile isn’t just for IT and I predict we’ll see more and more of this kind of thinking in the future.

What hat are you?

So, there it is, three resource management tips from wearing the thinking hat.  But de Bono’s concepts have other ways of making you think about how you think.  You can find your own copy of the Six Thinking Hats on Amazon.

Master Mariner – Any Gross Tonnage, Oceans

pleasurecraftoperator.gifIn Canada, operating a private motorboat requires having a Pleasure Craft Operator’s Card.  Now, after you get over chuckling about which bureaucrat made up the term, the basic principle is quite sound.  If you are running a boat with a motor, you need to get this competency card.  I’m proud to say I’m the holder of such a card to use my Chaparral motorboat during the summer. Getting my operator’s card required passing an exam that took about 45 minutes and required little study for me as I’ve been in and around boats since I was a child and had a father who made sure that no one operated a boat he was on without knowing the navigation rules.

That’s fine for my 8 person boat but what about larger craft?  The top license available is called a Master Mariner and it comes in a variety of flavors but the most advanced license available is called “Master Mariner, Any Gross Tonnage”, Oceans or otherwise known as “Unlimited Master Mariner”.  For anyone who has taken a cruise, it’s often surprising to find out the person in charge of the cruise ship is properly referred to as the ship’s master though pretty much everywhere we say “Captain” all the same.  Becoming a Master Mariner takes at least five years of highly structured training and apprenticeship.  It’ll be longer to become a Master Mariner, Any Tonnage and longer still to become a Master Mariner, Any Tonnage, Oceans.

Hold on, if you’re about to tune out.  I’m getting to the project management part now.

We have these well-defined structured training to let someone take charge of a large ship and sail it safely from Point A to Point B but we are much less certain of what is meant by a “Project Manager”.  Despite project management having been around since the dawn of time and project manager as a career, having been around at least several decades, we are not much closer to a common understanding of how to tell one project manager from another.

When I started in the industry, project managers were thought of more in the construction and engineering industries.  Those who could handle a project of “any tonnage, anywhere” were small in number and legendary.  These were the people you went to for the next Olympics or the next mega skyscraper.  Those folks are still around and people have apprenticed with them as a new breed of project managers coming forward.  But, in so many industries it is harder to get a handle on who can manage what kind of project.

In the past few years I’ve noticed a disturbing trend among project managers in association dinners and events I’ve attended.  There is a significant proportion of us who are more focused on our career opportunities than learning what we need to know next to take on the next sized project.  I see people on LinkedIn and working in project associations who are all about their resume and “spinning” their experience and not much about how much they know.

We’ve had the opportunity at HMS to interview people in the project management industry in the last couple of years and the results concern me.  A high percentage of those resumes I reviewed looked great and when meeting the people attached to those resumes, I asked more about their experience and what their actual responsibilities were on the projects they spoke of so highly.  Sadly, a high percentage of those people interviewed seemed to have learned very little and their actual experience was more as a project operator or functionary rather than as someone who could guide a project through a tough time.

Perhaps as our industry evolves we’ll find ourselves focusing more on longer term project training rather than the weekend courses and tests that seem so popular.  I, for one, would be delighted to find some international standards that are universally accepted for a master project manager that, just like those who take charge of ships at sea, include both theoretical tests and in-the-field experience.

There are numerous project certifications that are the equivalent of my Pleasure Craft Operators Card.  Mine took a few hours of study and testing and was accomplished over a weekend.  I hope one day soon we’ll see the project equivalent of a Master Mariner, Any Tonnage, Oceans.


Project management and the start-of-year challenge

It’s a brand new year! The Christmas tree is down and the ornaments packed away. The relatives have left and the New Year’s champagne is gone to the last drop. Now, you can return to work rested and ready to jump into the new year and get those projects back underway!

Not so fast.

For most project managers, there is a big checklist of start-of-year activities which are impossible to avoid. These challenges can be mini projects on their own and they are mostly due to fiscal year end activities that affect project managers. Let’s take a look at a few of these activities and how you can tackle them.

Fiscal budgets

Most organizations work against fiscal budgets. That includes, of course, projects. So, even though there is a budget that runs the length of the project and that project spans over the fiscal year end, there is also reporting and analysis that has to be used by finance to close out the year. There are a few ways to tackle this. One of the most common when using a desktop project management system such as Primavera P6 Pro or Microsoft Project is to just copy the whole project with a new project name and turn over the copy to Finance for use as of the end of the year. There won’t be any more input into that file, it will be a moment frozen in time at the end of the year. Then in the ongoing project file, baselines can be created so a comparison against wherever you were at the end of the year can be accomplished later.

When you’re using an enterprise system such as Primavera EPPM or Microsoft Project Server, this isn’t the ideal plan. Copying projects in that case tends to make the enterprise system think you have more work when you really don’t and integration of actuals from inside those products or from outside sources can make a mess of where the actuals need to be managed. For enterprise environments a more structured approach to the end of year makes more sense. Using a baseline to capture the end-of-year status is the first step. Then, making sure that rates or other budget-based elements are updated is the next.  Setting reports for the year and freezing those is often the next important step before getting the progress in for the early new year’s first progress periods.

Project Timesheets

Most enterprise timesheets have end-of-year processes that are a must to accommodate the needs of the Finance department. Make sure that your project timesheet completes the end of year tasks in a timely fashion. If you’re using our own TimeControl, we have recommendations on what you should be considering doing at the end of the year on the TimeControl Blog at

Tax Credits

Numerous organizations apply for Research and Development Tax Credits and being able to produce auditable reports from project management which match costing reports from Finance is essential to a successful Tax Credit claim. This is the right time to reach out to Finance to see what they will need from Project Management in the next few weeks.

Rate Reviews

The most likely time to institute rate changes on your resources is right this minute so check to see if any rate changes took place on the first of the year. If so, you’ll need to update rates for upcoming progress entry. Did I mention taking a baseline of the project? It’s a good time to do that! While you’re at it, an end of year backup isn’t a bad plan either.

Project Reviews

If you do stage gating or regular project reviews, now is a good time to make sure they’re up to date. With the new fiscal budget starting, projects which no longer hold promise of delivering a good return on investment might be considered to be paused or ended. Start the year off with a clean slate.

Tackling these tasks at the very start of the year can be a challenge, but trying to accomplish them in 4 or 8 weeks may be literally impossible so pushing hard now to find the time can save enormous heartache and more time later.

Either way here’s to a great New Year!

Happy Holidays

For everyone who has followed the blog this year I wish you the very best of the holiday season.  I hope you and your families are happy and safe this season and I look forward to our discussions in 2017.

Chris Vandersluis


All-in-one or Best-of-breed

swiss-army-knife-on-steroids_300x211.jpgAll in one thinking is built into our industry

Many years ago I wrote several articles about the differences in choosing an all in one Finance system vs best of breed functionality.  My focus was mostly about project management, but the concept can carry across many systems.

The notion of all-in-one corporate systems became popular in the 90s.  Large integrated systems like SAP or Oracle Financials were able to point to multi-function systems which included in their core modules the General Ledger, Accounts Receivable and Accounts Payable systems that we think of as common to all Finance systems.  Then in a second tier of functionality: Invoicing, Project Costing, Payroll and Inventory were attached.

The biggest barrier to these systems becoming pervasive was that integrating such varied functionality was often complex.  The stated benefit of using the all-in-one provider was that there was less work to integrate the different modules yet just defining the business logic of multiple such modules linking together can be an overwhelming project in itself.

So, the disadvantages of choosing best of breed didn’t seem so disadvantageous after all.

Yet, the concept of going with all one vendor has continued.

In the last 5 years there has been a push from the large scale integrators to move all business functionality to the cloud.  Office is the dominant word processing, spreadsheet, presenter suite and it is available online as Office 365.  Microsoft will explain that you can build any additional functionality you wish in its accompanying Azure system.  That’s awesome so long as you are ready to embrace all the Microsoft technology that’s already there.  So, if you prefer to do your work with any Oracle tools, this won’t be your best plan.

Oracle now has cloud offerings.  Enterprise Business Suite is one of the big competitors to SAP and it too is now available online.  Here too you can build whatever you wish inside of the Oracle cloud based architecture.  But what about Microsoft SQL Server?  No.  That’s found over on the Microsoft side.

What I’ve found fascinating about this is that in the last few years, just as it was in the 1990s, these systems have not become all powerful.  Microsoft has softened its “we’re all in” slogan to endorsing hybrid architectures where some functionality is online and some in house as the ideal.

Online infrastructure offerings such as Amazon’s Web Services (which host such modest online offerings as Adobe, Netflix and Intuit) continue to flourish.  How is this possible if all-in-one is all-powerful?

CRM systems are offered by both Microsoft and Oracle yet Salesforce still seems to be growing.  That makes no sense if all-in-one means always-better since Salesforce doesn’t offer core Finance modules such as a General Ledger or Accounts Receivable.

In my own industry, TimeControl has always lived as a best of breed solution.  Over the last 25 years we’ve had many requests for it to be extended to include all-in-one functionality.  We’ve been enticed to create a complete project planning or project portfolio management system.  We’ve been asked outright if we would extend TimeControl to be a payroll system and/or a Human Resources system.

Thus far we’ve resisted all these suggestions.

We are committed that TimeControl be the best of the timesheet world and TimeControl has become just that.  It is already the most flexible timesheet in our industry and the timesheet home for hundreds of thousands every week.

Yet that alone doesn’t mean that TimeControl is the ideal solution for everyone who finds it.  We encourage organizations to define their business problems before considering the solution and our prospective clients take us to heart.  We have asked more than one organization to pause for a moment to be sure they know what they are looking for before deciding that we are it.

Shouldn’t the same type of thinking apply to all software vendors?  Back in the early 80s when I first entered the IT industry, there was a saying “You never get fired for buying blue”.  It referred to IT purchasers selecting IBM as their vendor.  IBM’s logo was blue, you see and they were by far the dominant computing vendor at the time.  Large IT vendors who espouse all in one solutions have similar pitches.

How could you go wrong buying all Microsoft?  Or all Oracle? Or all SAP or all… well you pick the vendor.  The decision will always be defendable and in a complex IT market, it takes a seasoned purchaser and business analyst to pause long enough in the evaluation stage to make sure that the benefits of going with one vendor outweigh getting the best of breed for different functionality.

Yet, even in the large scale vendors, there is room to bring in “outside” systems.  We had a client this past year who informed their large scale vendors that their systems must support TimeControl as they had already deployed thousands of TimeControl licenses and the data from TimeControl was already well established as a core process and a core source of key metrics for the organization.  Magically, vendors who had said the only option was to go with an all-in-one, found their integration functionality much more interesting and the winning vendor got to work with us on integrating their systems with ours.

I would be remiss if I didn’t say that for some organizations, the all-in-one approach is ideal and a great fit for their requirements.  We have known many organizations who have successfully solved their IT business challenges this way.  My own HMS is partners with some of the largest IT vendors and we are able to work together on many occasions to make a solution fit the client.

Yet, as we approach that most festive of times for IT vendors (the end of the 4th Quarter and the end of this year’s quota’s), it is a better time than ever to make sure as an organization you are putting the business problems at the core of your search, not the promises of whatever vendor shows up next.

Make us do the work to show you how we can solve your particular business challenges rather than taking the path of least resistance and matching your requirements to fit the functionality presented.

Is the answer “All-in-one” or “Best-of-Breed”?

Doesn’t that depend on the question?



Tail wags dog

tailwagsdogMy staff have heard me use the expression all too often. “Tail wags dog! Film at 11.” As though it were a breaking news headline on CNN. I use the expression though to talk about organizations that approach our company with an interest in deploying our enterprise timesheet system or an enterprise project management system but have somehow gotten the cart ahead of the horse (Yes, I know. It’s another expression).

The conversation usually starts off quite normally.

“Hi, I’m calling because we’re looking for an enterprise project management system.”

“Great,” I reply. “How can I help?”

From there it’s all downhill.

“Let me send you our list of required features,” the caller announces and I wince in reply.

“Awesome,” I’ll say. “I look forward to it.”

The list that arrives is, sure enough, a list of features the organization has determined that it desires in its soon to be acquired enterprise projects system. The list can be short but it’s usually not. It’s a multi-page Excel workbook and it’s obvious from reading it that it has been assembled by a committee. Each interested party has had an opportunity to put what they want on the list.

Sometimes the list is weighted. The most popular weighting is 1) Must have, 2) Should have and; 3) Nice to have. Needless to say, 90% of the required features are Must-have’s.

Like all the vendors who have received this list, we respond of course. We can almost always tick off a “Yes” next to all but one or two required features and now the tail starts to wag the dog.

The organization receives similar responses from all the possible vendors and has a hard time trying to figure out who is the most likely winner of the selection. “How can this be?” You ask.

Most enterprise level project management systems are capable of delivering most of the more commonly requested features. Oh, they look different and they act different but based on the 10 or 20 word description of the feature, most vendors can either answer “Yes” or “Yes, with some effort” to all the requests. So picking the right software based on this plan has hit something of a challenge.

There’s a big missing so far in the analysis for those who have been around for awhile. Almost never in these documents do we find the business problems which the requested features need to resolve. If someone were to say “We need missing timesheet email notification to help mitigate the 30% of timesheets that can only be located now by manually and laboriously sifting through all the delivered timesheets, determining which ones are missing and then emailing or calling those people directly.” I’d be so excited, I’d write about it in these pages that very week. But this is decidedly rare.

Instead the organisation will now struggle to fit the list of possible features of each of their shortlisted products into problems they can find. It’s a solution, looking for a problem. Sound familiar? The tail is wagging the dog.

“How can this happen?” You ask.

It’s a fine question. Almost always, this is the result of good intentions run amok. The person given the analyst role in this requirements exercise gets lots of input. Everyone is trying to be helpful. But, the requests and even his or her own thinking is based in what will the solution look like. This is not at all helped by big enterprise project management software vendors showing brochures, talking to colleagues at trade shows and pumping out lots of literature about how many features we have. And, before anyone points out the obvious. Yes, HMS does this too. All enterprise software publishers do.

So the list of requirements becomes longer and more detailed and eventually goes into a purchasing evaluation process. There may be some part of the organisation that would be just as happy to have to write the system internally. This is particularly true if there are offshore developers on the team. A request for an IT system that could be written over time by a contractor is like candy for such people.

At some point the evaluation may require demonstration of the software. My least favourite demonstrations involve a pre-defined script written by the organization who as yet knows nothing about the software they’re purchasing and the script bears no resemblance to any employee’s actual work day. We try to talk prospective clients out of such scripts and focus instead on working through the kinds of problems that can be solved with TimeControl.

In my experience, if there are demonstrations involved, the organization will move forward with the vendor it “feels” most comfortable with. I say feels in quotes because organizations don’t feel anything of course. But those who are evaluating may feel that one vendor understood their issues more than the next.

So how do you get the dog to wag the tail; to get the horse to get in front of the cart? One things we do is to deploy in phases. We will do a pre-sales phase where we are identifying as many of the business challenges as possible. Then our technical staff will do a pre-deployment meeting in which assumptions we made get tested and validated by the client. When a business requirement seems fuzzy or less than certainly defined, we’ll recommend to deploy that in a subsequent phase. One thing we’ve learned for sure. No matter how well we define the requirements now, they will evolve with the client’s knowledge of the system they’re buying.

Organizations can insulate themselves from this problem by putting emphasis on the business problems they want to solve. In all likelihood, vendors will have different ways of solving those challenges and evaluating possible solutions from a perspective of “How did they solve my problem?” Is going to be much clearer than “How many features did they have?”

If a vendor and prospective client collaborate from the outset, then the dog will always wag the tail.

Give a man a fish and he’s got… a fish

fishingPerhaps you’ve heard the proverb “Give a man a fish, feed him for a day.  Teach him to fish and you feed him for a lifetime.”  The expression can be traced back to a novel from the early 1800’s called Mrs. Dymond but the sentiment of the expression is understood by everyone.  If you do something for someone else that’s a good thing but teaching them to do it for themselves is a much greater benefit.  Anyone who has parents knows the conflict of giving their child what they are asking for rather than helping them learn it themselves.  Homework time is an ideal place for this lesson.  It’s easy just to say “John, the answer is 4”, rather than sitting for the half-hour it might take to teach the formula behind the answer.

To be certain, John will be happier in the moment just to get the “4” but John’s parents know that in the future, knowing how to do the math will deliver incalculable benefits to their son.

In the last decade or so in business, I’ve seen more and more movement towards the short benefit rather than teaching how to do a thing.  The examples of this are everywhere.  At one time we would have pointed someone towards the Encyclopedia Britannica and said “Look that up.”  None of us do that anymore.  To my surprise, they’re still around, by the way.  I looked them up while writing this.  You can find the Encyclopedia Britannica at  It’s prophetic perhaps that I found the reference for Britannica and Mrs. Dymond the same way we almost all do.  I searched for the reference and followed the most relevant links.  We do this type of research now at our desktops or on our phones while we stand at a stop light, on our tablets as we’re reading on the bus.

Instant gratification.

We have a phenomenon today elsewhere that helps make the point from a different perspective.  If you’ve followed the increasing popularity of “helicopter moms” you know that these women (and sometimes men) hover over their children helping to solve their problems for them.  While it hasn’t happened to me, a colleague at one of the world’s largest software firms told that they’d gotten a call from one of their staff’s mothers asking why their son hadn’t gotten the raise and promotion that they’d hoped for.  Sound ludicrous?  I’ve spoken to several university professors who have received similar calls asking why their child didn’t get a particular mark on a paper.

Mom will take care of it.

I’m not knocking the instant availability of information at our fingertips or getting help from others when we’re challenged any more than I am giving food to someone who’s hungry or offering to help a child understand a concept they’re working on.

But, where can that get us into trouble?

In the last month I spoke to person after person in the days leading up to the election about issues only to find out that their sole source of information about that issue was Facebook or Twitter.  That’s fine and that’s their choice of course.  Not everyone needs to be a policy wonk like me but it feels more like my child asking me to do their science project.

Years ago I was asked to be a judge for my daughter’s high school science project.  It’s a disturbing and yet fascinating exercise.  You can spot the projects that mom and dad did for their child from across the room and it doesn’t take long when asking the student about their subject or their project to realize that they’ve been coached in a script by someone and as soon as they’re asked a question off-script, they demonstrate how little they know about the subject.

They didn’t learn to fish, they just got a fish to eat.

In project management systems, where I spend all my working time, I see similar problems.  On a regular basis I’m asked for features and functions to be created whose main purpose is to alleviate responsibility from the project manager for analyzing their own project in order to streamline or make the reporting of data easier.  I get all kinds of requests but here’s an example from over 15 years ago so I don’t embarrass someone who’s made requests more recently.

I was in a large conference room with over 20 people going through the functionality of a project tracking system.  There were representatives from Finance, Project Management, IT and the executive office.  Both the CIO and CFO were in the room.

At one point the CFO asked “Why can’t the system just update the task’s progress based on the effort completed?”

I was confused.

“What if we had a task scheduled for 40 hours and we’ve completed 40 hours of work?” I asked.  “What should the system do?”

“It should mark the task complete,” the CFO said.

I might have laughed but he was absolutely serious.

“What if it’s not?” I asked.

“But if you’ve done the 40 hours, you are complete,” he said, looking confused.

“But what if there’s still work left on the task?” I repeated.

“But how could there be?” he asked.

In the end, the CIO took the CFO out of the room and when they returned the question was over but the CFO definitely did not look happy.

Sound funny?  In a way it is.  But in a way, it’s really not and not because the CFO had a naïve notion that tasks never go over budget.  The issue I had with the exchange was that someone wanted a feature put into software that would have started marking tasks complete even though they weren’t.  Almost every software manufacturer I know gets these kinds of requests.  At HMS we get at least one a month.

The desire for cheap closure to a question is almost universal in the world of today.  Almost everyone wants the fastest path to an answer for things.  We have to write “Spoiler alert” just to give people who really want to read the whole book or watch the whole movie to know we’re about to read the last page out loud.  At one time this would have never happened.  I can still remember the movie “The Crying Game” coming out.  No one gave the ending away.  Everyone who saw the movie had a twinkle in their eye like they wanted to reveal the last scene but no one did.   I’m not sure the Crying Game could be a hit in today’s world.

In the business of project management systems and software, you’ll find the push to make things simpler, easier, less analytical, and more synthesized is a trend that continues.  It’s something you’ve seen me talk about as a cautionary tale in my writings over the last few years.  I’m all for making things easier but I am absolutely against the idea of letting a project manager or business analyst abdicate their responsibility for analyzing the status of their own project.  A project manager, to my mind, should never be able to say “Well, that’s what the software said.” in response to a question on why is this project in the state that it’s in.

Give a man a fish, he’s got a fish.  Teach him to fish and he will not only be a productive member of our community, he’ll be able to pass on his skills and expertise to generations to come.



The Power of Display for Project Managers

Many years ago I was forced to take an Economics Statistics course at McGill University in Montreal.  It was a requirement for my Economics Major and one of the most miserably tough math classes I’d ever encountered.

The class was taught by an older gentleman who was maybe 150 or maybe 160 years of age.  He had tenure, he immediately informed us so there was no one we could complain to when he would fail over half the class at the midterm (which he in fact, did).

I worked my behind off to scratch out a B- and was relieved to be through it.  (There were some people in the class on their third try to pass.)

To my surprise over the years, the class turned out to be as valuable as it was tough.  There were many aspects of the class that would come back to pay dividends.  When Monte Carlo simulation software became popular in Project Management circles, I found that I had a fundamental grasp of the subject that others struggled with.  When Six-Sigma became the rage, I was actually able to describe what the term meant and understand how important it could be.  Yes, these are all useful but the most important thing I took away from Statistics for Economics back in the 1980s was the power of display.

Consider the following two representations of the same data:



Your eye is obviously drawn to the much more graphical pie chart. Your brain can absorb the problem, see it in context and you are even called to action.  (Don’t you want to ask “What does unexplained time mean?” or “Please explain the unexplained time to me.” or, “Go figure out what is in that block of unexplained time!”)

If you wanted to draw attention to all the time your personnel are spending that has no explanation, then mission accomplished.

If however, you had bunches of unexplained time you were working on and didn’t want your project meeting bogged down in trying to explain it before you could figure it out yourself and wanted to redirect your project team meeting to more important items, then the first grid would be your friend. The “unexplained time’ would still be there.  The data is the same, but the display is dramatically different.

The same can be said for almost any aspect of project data. Imagine for example, that I display a budget vs. actual report on a project in progress like this:


The VP of Finance doesn’t need to see more than this.  “Cancel this project immediately!” is likely to be their comment.  After all, look at it!  The project clearly has problems.  The actuals  costs are way over the budgeted costs for the project to date seem out of control.

But wait.

Let’s put in my projections for where the project is expected to finish:


The project is running faster than projected and not over budget but under!  Now the VP of finance is all kinds of smiles.  Things are wonderful.  This is the best project ever.

The difference?  The power of display.

So, as a project manager you may be feeling from time to time that you are unable to get much traction.  You have no authority.  You can’t “make” people do what you want.  “You have no title that lets you control what other managers do with their time.  Despite having no authority you’re still very much responsible and even accountable; held to account for the success or failure of the project.

You may feel that you have very little power but in fact, just this one thing; this power of display, can move mountains.  Sponsors, executives and many other managers can be incentivized to do the things the project needs if they can just see them in a perspective that shows the very challenge your are trying to overcome.

Mark Twain once said “There are three kinds of lies: lies, damned lies, and statistics” and there’s a lot of truth to that statement but more important than the actual analysis that I learned about all those years ago in college is how you present your findings once they’ve been calculated.

The power of display is a tool that you shouldn’t forget about in your project manager’s arsenal!