Category: timesheet

Home timesheet

EPMGuidance changes are all done for now

Thanks for your patience as we updated the EPMguidance site.  Don’t worry.  The blog is still there in its entirety but the site now reflects some of the other activities that we do.  This isn’t a life change as I’m still the President of HMS, the publishers of TimeControl but now instead of spreading my other interests across multiple sites, I’ve been able to consolidate them here on the EPMGuidance site.

On my way to Dallas for the PMI Symposium

I’ll be headed to Dallas tomorrow (May 17) to speak at the Dallas PMI Chapter’s Symposium.  I’ll be talking about one of my favorite subjects, how to increase resource capacity without hiring.  It’s always a pleasure to speak with people who have similar business challenges about how to overcome them and I learn something new every time I get to engage in one of these dialogs.

Aside from my speaking opportunities, there are more articles to come in the next few days so stay tuned.

For more information on the Dallas PMI Symposium, visit: jindal.utdallas.edu/events/project-management-symposium.

 

A busy springtime

It’s been a busy time around here.  Aside from a may product release at HMS as we launched TimeControl 7.3, I’ve had some other activities underway.  This week I was delighted to be able to do a talk with the ProjectSummit*Business Analyst World conference in Orlando.  I do some volunteer time with the advisory board of the PW*BA conference.  I’ve been associated to ProjectWorld since the very first conference ever in Toronto over 20 years ago.  It has evolved greatly since then but I still enjoy any chance I can to work with attendees from the show.  This week the subject was how project managers can make an impact even though they often have little authority. The attendees seemed pleased.

Next month I’ll be taking a day to be in Dallas for the local PMI chapter’s annual Professional Development Days symposium. They’ve asked me to speak there on how to improve resource capacity without hiring; a subject that’s dear to my heart. For those in the Metroplex area, I encourage you to stop by the PMI’s website for more information at: pmidallas.org.

Can you be the same but different?

“Can your system help us? We have two distinct groups.”

This is a remarkably common request here at HMS. In our case we’re talking about how to take care of timesheet collection for multiple groups using our TimeControl timesheet system but the request is common to many project management environments. 

This comes up whenever we have multiple groups trying to use the same project control environment. From one perspective, there are many benefits to grouping data together.  From a very different perspective, there may be many legitimate reasons to keep the data apart.

Some project systems have tackled this by using multiple project environments where independent projects are somehow linked together. Other systems use filtering to keep the data in one place but act as though it is distinct.

Let’s take a look at the benefits and challenges of each approach.

Combined

In a combined environment, all project management data is in one database. Some of the benefits of this include:

  • Global reporting
  • A single system for technical maintenance or licensing and;
  • One set of standards

There are, however some immediate challenges:

  • Difficulty supporting different system settings. This can be as simple as the number of working hours in a day or the time zone of one group vs. another
  • Individual group reports
  • Different forms of analysis by group

The decision to group data together can deliver some economies of scale that is often worth the challenges if, the distinct requirements of each group can be somehow met.

Separated

In a separated environment, each group maintains its data in a distinct database or instance of the system. There some benefits to this too:

  • Each group’s setup is easier to define and deploy as there is no compromise to be made for the groups of other requirements
  • Security can be wrapped around the entire environment instead of within the system.
  • Standards are faster to determine as only this group must be accommodated

There are challenges to this environment also.

  • Global reporting can be either impossible or, at least much more challenging than in a Combined environment.
  • Multiple systems or instances must be maintained technically
  • The lack of centralized standards will carry forward to process and procedure and this will make interpreting the combined data as much more challenging

So? Which is best?

There is no obvious answer to this question. But, as a system publisher, we have had to tackle this challenge.  Our decision with TimeControl was to prefer Combined environments.  But, even as we created the support for this, we have been faced with how to support the individual requirements to allow each group to enjoy their own individual settings while living in a single instance with other groups or divisions.

Our approach was to embrace flexibility across the spectrum of functionality within TimeControl. We put an emphasis on full-feature filters on every element of the system.  You could display or hide table records from one user-profile to another.  Profile security had to go to the field level so user defined fields could be displayed or hidden by role.  Business Validation Rules could be global or could be specific to only one group.  Languages could be adjusted by user profile so that terms that are appropriate to one group show up differently than another.  Reporting would show only the data to which that user had access.  This is all completely transparent to the user.  After all, all they care about is finishing that timesheet as quickly as possible late on a Friday afternoon so they can go home and enjoy their weekend.

Virtually all parts of the system could appear to be independent yet in the background still be part of the same database.

From the publisher perspective it has been a lot more work but the payoff is in the eyes of the client. We have been able to support organizations with thousands and thousands of users, divided by division or group or geography without having to resort to separate instances of the system.

Being able to be the same but different is just the water we swim in around here.

I’m delighted to be in the Globe and Mail, Canada’s largest national newspaper

There are a number of articles and some soon-to-publish in the works for EPMGuidance but I thought I’d share some writing that has appeared elsewhere.  Last month Canada’s largest national newspaper the Globe and Mail asked me to contribute a piece to their Leadership Lab.  The article discusses how a niche business like my own HMS Software has been able to be so successful at having clients many times our size.  Since we started in 1984, HMS has always served medium and large sized organizations.  It’s something we’re very proud of but since it’s something we do all the time, we don’t spend a lot of time thinking about it.
Our entire staff, sales, marketing, development implementation, consulting, training and even administration is all focused on producing satisfied clients.  That’s true for new prospective clients but it’s equally true for existing clients.  You’ll find the results on our website at TimeControl.com, in the collateral available from the the site or the TimeControl blog at blog.TimeControl.com, in the way we present our products and services and even in how we promote ourselves.
The Globe piece tells how any company can be effective at applying those principles to larger clients.  You can read it in its entirety at the Globe and Mail Leadership Lab.

There’s still time to save on registration for the Orlando Project Summit

pwbawlogo300x51As followers of the blog know, I do some volunteer work with the ProjectWorld*Business Analyst World Orlando Advisory Board.  I’ve been involved with Project World since its creation 21 years ago and have been privileged to speak at many of the conferences.  I will be speaking again at the Orlando Summit which will be from April 16-18, 2018.  If you are interested in attending the conference, early registration discounts are available until February 10 at:  https://www.pmbaconferences.com/orlando/registration.html?utm_source=PMBA_ORL&utm_medium=Pop_up&utm_campaign=PSBAORL18-10.

I look forward to meeting some of you there!

 

Online or OnPremise Webinar series

You’ll find here the index of the webinar series OnLine or OnPremise which discusses the key elements of choosing between purchasing software for an on-premise installation vs. subscribing to software in the cloud.   Each webinar is only 5-6 minutes long.  You can watch the webinars in sequence if you prefer but they do not need to be seen in any particular order:

Download the complete slide show at: OnLine_or_OnPremise.

Mismatched Expectations

In today’s Agile-oriented software world, it’s all too tempting to skip the important steps of defining the work completely. There is no doubt that there is a meeting of minds between the client and the developers to end up with a product that fulfills the client’s desires and is of high quality and rapid arrival but once we get into the actual management of the project, there are differences in perspectives that are not obvious.

A client will make a request for a feature that they may be quite clear about but haven’t thought out all the implications of. In a perfect world, a Business Analyst would work through these requirements with the client in a user story to walk through how that feature should work and, hopefully, what happens after the feature works as they walk through the whole workflow.

The world is sadly not a perfect place.

Even when a BA is working on the project, we often see a feature request arrive to developers that describes the request adequately but does little to address the impact of the feature. The client’s perspective has usually shifted from “I have this business problem I need solved” to “This is the feature I’d like”.  Those are two very different goals.  The discussion becomes feature-centric.

The developer’s perspective is typically all about how to do something, not whether it should be done at all or if there is even an alternative to the feature.

In our office we have a checks and balances system that puts feature requests through a couple of people before they’re accepted and often results in the feature being delivered in a way that wasn’t originally anticipated but is much more effective or which avoids collateral damage to other aspects of the system that had never been originally thought out.

Still, even in my office, we end up with clients and our staff working at cross-purposes. Just like that old expression, “The road to hell is paved with good intentions,” these moments start off with good intentions.

The problems are almost always in a part of the project where change management is possible or during the user acceptance phase and the issue is wholly due to mismatched expectations.

The client, like all clients, wants a change. Perhaps they’ve now seen what they requested and on screen it looks very different from what they had anticipated.  Perhaps the end-users hadn’t been fully included during the design and now that they are looking at the screens during testing, they not seeing the benefits of the new system.  Perhaps the client just had an improved idea.  Whatever the stimulus, the result is a request for something different and as is always the case, the pressure is on to deliver it right away.

Unlike during the design phase of a project when many resources are associated to reviewing and game-playing the work flow of a design, the request may seem innocuous but it is easy to have a tiny request become a major heartache.

With TimeControl, requests for changes from clients are usually able to be handled during the configuration of the software but even here we can have challenges. Making a key design decision about how long the timesheet period should be can have massive implications later.  Should it be weekly, daily, bi-weekly, bi-monthly, monthly?  We always take time to work through the implications of this as it affects how approvals, validations and workflow will work later but even here, we’ve had more than one client get through the deployment and then call to say, “I know we said weekly but could we switch to bi-weekly?”  The answer to these things is often “Sure… but a bunch of your configuration will need to be redone.”  In the end we wrote a whole white paper on the subject to give clients an easy vehicle to pass around all possible involved parties in the office for the discussion of that one implementation decision.

When our technical staff interact with our clients, they are always oriented around satisfying the client. That can cause heartache too.  Sometimes it is best to say to the client, “I hear your request but before I say we should do it, let me walk through the implications of the request.  Once you hear them you may change your mind.”  However, if you’re someone who is all about satisfying your client, that’s not a sentence that is immediately thought of.  Instead, and especially under pressure, a technical person might say.  “I will do my best to do that right away,” not even pausing themselves to walk through the implications.   Our own process catches most of these requests but some still slip through.

In the end, the best thing to think of when there are requests from a client to a developer, whether that happens during the bid phase, design phase or at any time later is to pause a moment and make sure that the thinking of both sides are on the same page.

A couple of key questions for the client to ask might be:

  • How much effort are we talking about?
  • What implications will this have on our data?
  • Are there any implications of this request that will impact any other part of our design?
  • How will we test this new feature to ensure it delivers exactly what we want?

Key questions for a developer might be:

  • What is the business challenge that you hope this feature will solve?
  • Are you clear that this is a change request that will affect the cost, schedule, testing of the project?
  • Have you walked through this request with other impacted parties on your side?
  • Have you considered how you will test this feature to make sure it doesn’t affect anything else in the system?
  • Is there a way you could fulfill this business requirement using other features or in another way?
  • What is the priority of this request compared to the others we are already working on?
  • Is there a completed design for this request that considers how it will fit into your existing workflow?

In the end, these questions just serve to have all parties pause for a moment and ensure that the perspective of both parties are aligned.

 

 

 

There’s no cheese down that tunnel!

In my brief flirtation with Psychology in my first year of university, I learned more than I’d Wendy_300x274ever want to know about rats in a maze.  My distaste for the exercise would come back to haunt me last year when my stepson needed a dwarf hamster for his science project.  Wendy is now a part of the family.  You can see Wendy and our home-made maze on the right.

You’ve no doubt seen the images I’m talking about.  You put a piece of cheese that the mouse or hamster loves at one end of the maze and you drop him (or her) in at the other end and time them over and over and over and over again running through the maze to see if they can Maze_300x291learn how to get to the cheese more quickly by avoiding wrong turns.

Then, when you know the poor animal has learned perfectly where the cheese is, you remove it.

The mouse or hamster will go back down that tunnel over and over again, certain that the cheese will be there next time.

The difference between humans and hamsters is that eventually the hamsters will quit.

We humans are, as a species, obstinate.  If we think there’s a favorable result down that maze somewhere, we’ll keep going until we starve to death.

I’ve had a couple of projects that have been in this category for some time.  One project involves the link with a piece of software from a vendor that we’ve worked with for decades.  Some time ago, they released a new version of their software and suddenly the link we’d counted on for ages didn’t work properly.  We asked the vendor if they knew what we should do and they didn’t and the developers who have worked on this have made a number of attempts to solve the broken link.

The problem is, that despite being brilliant developers (much smarter than myself), they have focused over and over on the one bit of code that throws an error.  We know that error very well by now and no matter how many times we look at that one tiny bit of code, it won’t work.  Oh they’ve tried getting to the reluctant command in different ways, some of them very clever but we’re still at a standstill.  It’s the cheese-less tunnel for us.

This week I put the challenging project back on the books and told the staff to throw out all the legacy code for the module.

“Start from a blank page,” I said.  “Your job is not to make that code work.  We threw out the code.  Your job is to solve our basic business challenge as though looking at it for the first time.”

The thinking on the project has already changed.  Instead of working on the one command from this vendor’s product that isn’t working, we’re looking at all paths of movement of data from our system to theirs that results with data in the right place.  It turns out there are quite a number of options which we’d never tried.

It’s not unusual in a project to head down one path, hit some barrier and then pause while you wait for the barrier to be resolved but the lesson for me in this project is that you can wait at a barrier too long before it makes more sense to back up and try some other route.  In this case, closing down the path we’d been on for so long is forcing the developers to rethink the entire exercise laterally instead of literally.

I don’t actually care what the path to success is so long as we get there.  That a particular method fails is less interesting to me than the end result of solving the business problem I started with.

Over the last few attempts, we’ve had reactions from our staff that want to place the blame on the other vendor, or the indignation that their software doesn’t work as documented or on the righteousness of our approach.

None of those gets us the cheese.

I’m quite optimistic now that we’ll finally solve this particular challenge.  I’ll keep you all posted on our results.

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?

No.

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.