Managing Expectations: The Myth of the Non-Existent Timeline

If you live and work on planet Earth then you’ve experienced something like this:

Joe: Hey Suzie, can you get me X.

Suzie: You betcha’, but I’m pretty swamped right now. When do you need it?

Joe: No rush… whenever you get to it.

managing expectations

Joe and Suzie think they’re on the same page. Solid.

It seems like a harmless exchange so far. Unfortunately, there’s a decent chance this relationship is about to take a nasty hit. Remember, Suzie said she was busy. What happens to a task that doesn’t have a defined timeline when you’re busy? Usually, nothing. Fast forward 3 weeks…Suzie’s been tied up with “high priority” tasks, some of them were even items for Joe:

Joe (now frustrated): Hey Suzie, where is X?

Suzie (sensing Joe’s frustration and getting defensive): I just haven’t been able to get to it. I thought you needed it “whenever…”

Joe: Well yeah, but that was like 3 weeks ago. What have you been doing all this time? This is a small task!

Suzie: Fine! I’ll drop everything and have it for you tomorrow.

Joe: Fine!

Suzie: Yeah, fine!

miscommunication leads to anger

Turns out, Joe and Suzie weren’t even reading the same book.

Boy…That escalated quickly. The problem all started when Suzie and Joe decided to move forward without agreeing on a delivery date.

Every request comes with an expectation of when it will be delivered, even if the requester can’t or won’t identify it. When someone says “Whenever you get to it” they really mean “This is a really easy task and surely you’ll get it before the next board meeting in 3 weeks, so I’m not going to be pushy and set a date.” Or even “I know when I need it, but I’m not going to tell you because maybe then I’ll get it early.” Or maybe they just haven’t consciously acknowledged that there is a date they need it by. Whatever the case, it’s trouble.

Here’s a personal experience: A few years ago I decided to lease my first brand new car. Upon closing the deal I told my dealer that I was in no rush and that it was ok if it took a week or two to get the car delivered. And I wasn’t lying, it really didn’t matter to me. However, the dealer insisted he was getting me into my new car by the end of the week. It was important to him! With his assurances in mind, every day that week I got a little more excited about my new car and by Friday, I was stoked to go pick up my new ride. So, when I found out my car wasn’t ready, I was pretty annoyed. I grew increasingly annoyed and ended up flat out mad as more days went by. Finally, the car arrived about a week later. It didn’t matter that I’d started out with no firm delivery date in mind, the dealer set a date of his choosing and then missed it, turning a win into a loss by mismanaging my expectations.

So, what should you do when a client asks you to accomplish something but doesn’t give you a deadline or timeframe?

Look at your workload, identify a place where the task fits, add some buffer, and provide a delivery date to the client. If they accept your date, great! Now, you can focus on delivery. If they reject your suggestion, you’ve just uncovered the hidden time constraint. Now, you’ll be in a position to negotiate and agree upon an acceptable date.

Congratulations, you’ve just averted a crisis by successfully managing your client’s expectations! This is easily one of the most important factors for providing great customer service, keeping your client happy, and maintaining a positive relationship during your work together.

Side note: If there really is no due date, then, in my opinion, there shouldn’t be a task. If something is so unimportant that it doesn’t matter when it gets done, why on earth would you ever spend time doing it?

Advertisements

4 Questions a Software Developer Should Ask Each Day

This is my take on a lesson I was taught very early in my career.  It made sense to me right away, but after applying it for over a decade I’m convinced its one of the most important things I’ve ever learned.  I hope to do it justice in sharing it with all of you.  I’ve written this from my perspective as a custom software developer and consultant, but I believe it applies universally to software developers.  If you’re an in-house developer, just think of your clients as the folks you build software for (i.e. the users, your managers and the owners, etc).  Start by asking yourself:

Question #1: Is your client happy?

This should be the first thing on your mind at all times.  A happy client will come back for more. They’ll tell their friends about you.  They’ll promote your brand.  They’ll keep your pipeline full.  Clients are your lifeblood and keeping them happy is the only way to survive long-term.  I know… this is obvious, right?  Well, it’s not that easy to execute on all the time and a lot of developers don’t really understand what it means.  We’re not looking for short-term happiness brought on by just doing whatever they ask or by applying quick fixes in difficult situations. We’re after long-term, sustainable happiness.   How can we achieve that?

Manage Expectations:

This is huge.  You have to start managing your client’s expectations the moment you meet and continue doing so throughout the course of the relationship.  The moment you stop filling their heads with facts, they’ll start filling it with all types of other things.  Expected timelines will creep, visions of features will morph, old conversations will take on slightly skewed meaning in the light of new information that isn’t shared and wasn’t part of the original conversation. Expectation creep is not malicious… its human nature.  Small expectation gaps are like a crack in the foundation of your house.  With effort you can avoid them in the first place, but if allowed to form and grow they can be devastating to a relationship.  Communicate clearly, completely and often. And memorialize EVERYTHING in writing.

Honor your commitments:

Lots of promises are made at the beginning of the job.  Most of them will be recorded in a contract that commits you to honor them. However, not every intention, notion and promise will make it in there.  There will always be a new way to look at a deliverable later on and re-interpret its meaning. This tends to happen when the going gets rough. Maybe things are taking longer than anticipated. Maybe you’ve had staff or personal issues that distracted you from the project.  Stuff happens.  Renegotiate the terms if it’s reasonable to do so, but don’t, under any circumstances hide behind a nuance in the contract language or try to back away from the original spirit of the deal.  You know what you committed to. Honor it and get the job done. It will hurt at times, but your client’s happiness and your reputation depend on it.

Be a partner:

You’ve agreed to help your client solve a problem.  The best way to do that is to look at the issue as your own.  Do your best to see and feel the goals from your client’s perspective.  Own the problem.  Your client can tell the difference between this approach and that of the last firm who was just “doing their job”.

Be Available:

You should return calls/emails in a reasonable and consistent amount of time and you should answer the questions contained in them.  If you take long, random amounts of time to respond you’ll frustrate your clients. If your late response doesn’t answer the question, you’ll infuriate them.

Stick to your principles and do the right thing:

Your client hired you because they don’t have the time, or more likely the expertise to accomplish the task.  Even though you’ve been brought in as the expert, there will come a time where the client insists you to do something that you know will hurt them in the long-run.  It’s your duty to hold your ground in these situations. Take time to explain why this approach will be harmful. Give examples. Be steadfast. Ultimately it’s their decision, but you owe it to them to try and do the right thing.  I often liken this role to that of a personal trainer.  If your client came to the gym and told you they were tired and didn’t feel like working out, you could satisfy their short-term desires, buy them a muffin and a shake and plop them in front of the TV for a little Judge Judy, but that’s the easy way out and it won’t help them accomplish their long-term objectives. It’s your job to get them motivated and on the treadmill.  Don’t be a coward… do your job!

Be enjoyable to work with:

Make a connection with your clients on a personal level.  Ask them about their kids, their pets, their hobbies.  Be human and have a sense of humor.  Your client will like you if you help them solve their business problems.  They’ll love you if you help them have a good time doing it.

Be humble:

I’ve already stated that you’re here as an expert, but that’s probably only true for your specific role in the overall initiative.  Whether you’re building software or developing a social media strategy, you’re doing it for them.  Don’t come in acting like you’re the savior.  Do your part and do it well, but trust that they understand their business better than you do and they have the grand vision.  This is a learning opportunity for you and it’s probably the best part of being a consultant.  Listen intently, learn from them and make sure they know you’re doing it.

Question #2: Is your work correct?

If you’ve executed on the principals from #1, your client’s in a happy place.  Now it’s time to deliver and your solution better work.  It must accurately achieve the goals of the project in a meaningful and sustainable way.  It has to work today so that they can execute their business plans and begin to see some return on investment.  It has to be flexible enough that it can be modified as their business evolves.  It has to be scalable so that it will remain viable as their business grows.  Ultimately, this becomes an extension of #1.  Your product speaks for you when you aren’t around and it should continue the good work you did from the beginning.

Question #3: Is your work on time?

So you’ve got a happy client and a solution that works.  Next, you need to ensure that everything is delivered on-time.  Every project you take on becomes part of some larger business plan.  Once you commit to timelines, your client begins to plan their next steps.  Let’s say they’re planning a major product launch to coincide with the release of the new web site and online catalog you’re building for them.

They’ve got billboards going up, commercials ready to air and an army of trainees preparing to handle the expected influx of business…. and it all hinges on that end of year delivery your promised.  Now imagine its mid-December and you tell them you won’t be hitting your date.  It’s a client happiness catastrophe!  Months of planning is coming unraveled, your client cancels holiday bonuses for their staff because they need to conserve cash to pay the army of trainees with no corresponding revenue offset, they can’t cancel the billboards and commercials and they’re going to look like fools when they don’t deliver the product their hawking; oh… and your client is really starting to worry because they have a family vacation planned for the month after the project was set to be done and now that’s in jeopardy.  This may be an extreme example, but rest assured that your missed deadline will cause problems for you client that you may never even know about.  All you’ll know is that despite “everything you’ve done for them” your competitor wins the next job.

Question #4: Is your work on budget?

I bet you didn’t think it’d take this long to talk money.  Don’t get me wrong… budgets are important, but less so than client happiness, quality and timelines when it comes to your long-term success.  Simply put, you must never sacrifice #’s 1-3 to keep your budget in line.  That’s short-term thinking and it’ll eventually lead to a crippling pile of problems that will crush your business and reputation.  In a recent post titled Keeping Projects on Budget, I explained how an end-to-end project management effort is required to walk this line.  You’ll need to develop a process that works for you and execute it flawlessly.

One key topic to keep in mind along the way: Don’t do Out of Scope work for free!  I mean it… never ever ever ever. Not even small stuff.  Given the flexible nature of software, it’s easy to throw in this tweak or that additional feature.  It seems harmless at the time, but it always leads to problems.  First off, you’re mismanaging expectations.  You’ll be more likely to agree to something extra at the beginning of the project when you have lots of budget then you’ll be at the end when the budget’s winding down.  When you say yes, yes, yes then no, your client starts to feel cheated.  Why are you tightening the reigns now?  This leads to unspoken animosity where the developers think their earlier “generosity” is not appreciated and the client thinks this new strictness means the development team isn’t willing to see their “promises” through to the end. Everyone’s right and everyone’s wrong. It’s a bad situation and it damages relationships.  Secondly, now you’ll have to finish the scoped items with less than the necessary budget. You’re faced with sacrificing quality or sacrificing your profits.  That sucks.  See #2 for advice on what to do.

Summary

Software development can be a tricky business.  Most developers can handle the technology, but many struggle with managing the overall process.  Ask yourself these questions daily and align your efforts with satisfying them in priority order.   It takes time and effort, but if you persistently follow this list you’ll build great relationships, feel good about the work you do and eventually… you’ll make some money too.

I’m always looking for new tips and techniques for keeping my clients happy.  What’s worked for you?

Recommended read: While researching for this post I came across an article I liked so much I had to share.  A short, but important read: Mastering Account Management: 5 Tips for Keeping Clients Happy

Keeping Projects on Budget

BudgetYou know the drill.  Some ridiculously high percentage of software projects go over budget… And you’ve heard stories to back it up. Or worse, you have your own tales of being hung upside down by your ankles while the developers shake you down for every last cent.  Yet, here you are.  You’ve got a problem and it seems the only solution is custom software.  You’re doomed, right?  You might as well get ready to grin and bear it as you’re no doubt about to head down a path of endless pain and misery.  How did it ever come to this?

It doesn’t have to be this way!
I know… suspend disbelief for just a minute.  It’s going to take a lot of planning, coordination and hard work, but a well-executed software project can stay on budget AND deliver you a solution that satisfies your objectives in an effective and lasting way.  Here’s how we’ll help you do it:

Initial Sales Meetings and Preliminary Requirements Gathering
We start every engagement with an open mind. It’s important to fully understand all of the issues and goals before committing to any particular solution or technology.  Our initial meetings are designed to learn about your business and the issues you face.  What are the specific problems you are trying to solve and what are your goals?  Essentially, we start by helping you to define what success looks like for your project.  With that understanding our team will draft preliminary recommendations and deliver those with ballpark estimates.  At this point, we still won’t have all of the knowledge required to solve your problems, but we definitely have enough to determine if we are in the same ballpark… that is, determine whether or not we should continue before you spend any money.  If we are, the next steps will be to propose a formal Requirements Analysis process.

Requirements Analysis (RA) Phase
In this phase you’ll formally define what we are going to build.  We’ll schedule a number of meetings (preferably face-to-face) where our staff will spend time with your team to define the nitty-gritty details of the project. We’ll ask questions… I mean A LOT of questions.  We‘ll gain an understanding of your workflows, your staff, your business cycles, etc. so that we can clearly identify all of your needs.  With this deep understanding, we’ll produce several outputs that will help you effectively solve your issues within a predictable budget:

  • Business Requirements Document (BRD) – This is a comprehensive, plain-English, easy to understand definition of what you’re asking us to build. It can be read and understood by anyone on the project team, regardless of technical ability. The BRD is the cornerstone of the project and plays a fundamental role in sending you down a path where a predictable outcome and budget is possible.
  • Screen Mockups/Wireframes – These will provide a roughed-out visual representation of the system. They will help you to gain a better understanding of how the system will look, flow and feel.
  • Flowcharts – These are a visual representation of the workflow and business rules for the more complicated sections of the system.  They will help to further iron out the finer details of the project and identify “holes” early on.
  • Fixed fee for implementation – Once we know exactly “what” we’re building, we can very accurately predict how long it will take and how much it will cost.  That allows us to provide you with a fixed fee proposal for implementation.

In addition to these outputs, we will provide you with guidance on infrastructure needs, licensing for 3rd party components, and requirements for any 3rd party vendors, plus details on what your team will need to do to keep everything on track and make the project a success. Getting all of these issues on the table early and working together on a plan for dealing with them is the most important step towards a path that allows for a predictable budget.

The outputs from RA are yours to keep and are designed in such a way that any development shop with the appropriate technical abilities could implement them for you.  We certainly hope that you’ll choose to continue working with us, but at this point you are free and clear to move on if that’s what ‘s best for your organization.  And the best part… you’ve likely gotten here in less than 20% of your overall project budget.

Implementation
Once you agree to our fixed-fee proposal we’ll begin to implement your solution.  As far as the agreed upon scope is concerned, you won’t have anything to worry about in terms of budget.  We’ll produce the agreed upon output for thee agreed upon fee.  However, there may still be other costs that need to be managed.

Out of Scope (OOS)
We’ll continue to spend a lot of time with you during the implementation phase.  In particular, we’ll have regularly scheduled demos and walkthroughs that will allow you to see, feel and tweak the system throughout the process.  Minor adjustments to layout, appearance, terminology, etc. are expected and this is taken into account within your fixed fee.  However, you will inevitably identify additional opportunities for enhancements/changes that were not thought of during the RA phase.  Many of these items will be relegated to a future phase, but some may represent such a benefit to your solution that you choose to implement them now.  We’ll tap our vast project experience to help you classify the items and advise on how to best fit in those “must haves” with minimal impact to your timeline and budget.

Third Party Vendors
Very often you’ll have additional vendors that play roles in your solutions (i.e. your IT staff, your hosting company, the firm that supports the application you have asked us to integrate with, etc.).  This can create pressure on timelines and that can have an impact on your true costs (even if just by requiring additional time investment by your staff).  We’re very experienced in dealing with these situations and will advise you on how to get commitments from these parties and hold them accountable to meeting them.

Adoption
Once your software is complete, you need to get your users to use it.  This involves training, planning cut-overs, etc. and these things can definitely impact your true costs for the project. Having deployed hundreds of systems into organizations of all sizes under a wide array of circumstances, we’re able to advise you on a roll-out strategy that will help this all happen predictably (and on budget).

Quality Assurance (QA)
Your project has been in QA since the RA phase. Our QA team is tasked with reviewing and approving your Business Requirements before implementation can begin.  Then, the QA process continues through implementation with Code Reviews and internal screen reviews. Finally, the resulting software is put through a rigorous final QA pass that verifies all of your business rules and may include load tests, security scans, etc.  How does this impact the budget?  It’s all included in the fixed fee, but the value goes beyond that.  By ensuring a quality product goes out the door, we’re really enabling you to predict the long-term operating costs of the solution.  That will keep you “on-budget” for the long haul.

Ongoing Support
Depending on your specific situation, there’s a very good chance you’ll need or desire some level of support from our staff post-go-live.  With a full-time help desk and available 24x7x365 support solutions, we are equipped to provide you with a long-term support arrangement that meets your budget and business needs.

Deployment
Once everything is done, we still need to launch your software before you can start using it.  Delays of any kind will likely impact your total costs (i.e. think costs associated with preparing your staff for a launch that doesn’t happen, then doing it all over again a week later). Our development process takes a structured approach to this as well.  With thorough checklists in hand, our staff will be able to launch your software on schedule and will be less likely to run into last second “surprises”.

Summary
Our development process has been defined and tuned over the past 15 years through the experiences gained in thousands of engagements.  Our comprehensive approach, combined with the vast experience of our staff, allows us to identify and address hurdles early on and helps to eliminate the big “surprises” that plague so many software projects.  This allows predictability… And predictability saves budgets.

Is Encryption Required by HIPAA? Yes.

Ok… technically that’s not 100% true.  The HIPAA Security Rule doesn’t explicitly require encryption of data at rest, or even during transmission. However, this doesn’t mean what people think it means and that misunderstanding is getting a lot of folks into trouble (literally).

The HIPAA Security Rule is a 3-tier framework broken down into Safeguards, Standards and Implementation Specifications. Within the Technical Safeguards, both the Access Control Standard (i.e. data at rest) and Transmission Security Standard (i.e. data in motion) have an Implementation Specification for Encryption. Neither of them are “Required,” but are both listed as “Addressable.” So we’re done, right? Not so fast…. From the HHS FAQ:

“In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification:

  1. Implement the addressable implementation specifications;
  2. Implement one or more alternative security measures to accomplish the same purpose;
  3. Not implement either an addressable implementation specification or an alternative

So… it’s not required.  But HHS goes on:

“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”

The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:

“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing.  The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”

Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.

Mobile Devices

If you check out the HHS Wall of Shame where breaches involving 500 or more patients are posted, you’ll notice a very large number of lost or stolen laptops that were not encrypted.  In a comment about the settlement with Hospice of North Idaho that involved a stolen laptop, OCR Director Leon Rodriguez said: “Encryption is an easy method for making lost information unusable, unreadable and undecipherable.”  And it really can be easy. You can purchase inexpensive encrypted hard drives for all new laptops and install 3rd party tools on old ones (see Five Best File Encryption Tools from Gizmodo).  If you have mobile devices that may contain PHI and are not encrypted, stop reading and go encrypt them right now. Seriously.

The Data Center

Many people have bought into the idea of encrypting mobile devices, but not their servers. To an extent this makes sense given that most breaches have resulted from lost or stolen devices and not so much from hacking.  However, Leon Rodriguez noted in a presentation at HIMSS13 that he anticipates hacking to be a threat that will likely grow as time goes on, and the best protection in that scenario is data encryption. This is a more complicated issue for sure, but there are lots of tools and techniques that make this very doable. I plan to elaborate on those options in an upcoming post.

Data in Motion

I’m not going to get into much detail on this one. Use SSL, VPN, or some other method of encryption when transmitting your data over public lines. Period. If you have a scenario where it is “reasonable and appropriate” to send someone’s health information in plain text over the public internet, I’d love to hear about it.

Conclusion

You’re required to encrypt PHI in motion and at rest whenever it is “reasonable and appropriate” to do so. I’ll bet that if you do a proper risk analysis, you’ll find very few scenarios where it’s not. Even if you think you’ve found one, and then you’re beached, you have to convince Leon Rodriguez and the OCR, who think encryption is both necessary and easy, that you’re correct. Is that an argument you want to be making in the face of hefty fines?  Not me… and that’s why I have convinced myself that encryption is required by HIPAA.

How The Direct Project Will End Faxing In Healthcare

What is the Direct Project?

It’s an open source initiative being convened by the Office of the National Coordinator (ONC) to establish a means for secure communication of medical records between providers, laboratories, hospitals, pharmacies, and patients. Rather than devise some elaborate scheme and then cram it down the public sectors throat, the ONC decided to ask for help in developing a standard that used existing technologies to establish a nationwide exchange. The private sector stepped up to the plate with big name participants including Microsoft, Google, IBM, GE, Intel, and many of the major EHR/HIT providers.

How does it work?

To oversimplify, it’s basically secure email and it can be configured so that you use your existing email client (i.e. Outlook) to send and receive secured transmissions.

Sure, the underlying technologies can sound complicated. The Direct Project Overview describes the technical implementation as follows:

  • Content is packaged using MIME and, optionally, XDM
  • Confidentiality and integrity of the content is handled through S/MIME encryption and signatures
  • Authenticity of the Sender and Receiver is established with X.509 digital certificates
  • Routing of messages is handled through SMTP

To the untrained eye that’s a lot of acronyms and probably sounds like a monumental task to implement. The truth is, as far as technology goes, we’ve all been doing this stuff for a long time. That’s the beauty of the solution that the Direct Project and its community have established.

Are people actually using it?

Absolutely. The original pilot programs can be seen here and new ones are popping up everyday. For example, Clinician-to-clinician Direct Messaging just went live in New York State). Many Electronic Health Record (EHR) providers are adding these capabilities to their platforms. Personal Health Record (PHR) platforms like Microsoft Health Vault already utilize Direct messaging to allow patients to send and receive secure emails with their providers.

There is a problem though…

In order to send secure messages, you must establish a trust that ensures the sender and recipients are who they say they are. Users establish this trust with their Health Information Service Provider (HISP) – a role often fulfilled by their Regional Health Information Organization (RHIO). With this, the individual can easily exchange secure communications with other users who subscribe to the same HISP. The problem is that you typically cannot send a Direct Message to users who subscribe to another HISP. The ONC calls this “Pockets of Automation”. The technology is there to do it, but the HISPs effectively don’t yet trust each other (at least not enough to hand off patient data).

The ONC and the Direct Project community are on it. They held the Direct Scalable Trust Forum in November of 2012 and Deloitte Consulting released a report on their findings on February 6, 2013. As usual, the project community has set some aggressive goals and agreed on the following targets:

  • Feb 2013 – ONC to provide a “Ready to Go” set of policies, pilots, and education for vendors
  • Apr 2013 – Accreditation bodies formed, operating, and ready for business
  • Sep 2013 – Half of HISPs participating in accreditation

Ok… so what does all that have to do with faxing?

The federal government does not want you sending personal health information (PHI) via fax and as soon as they are able, they will make it illegal to do so (and unless you’re taking some pretty specific steps today, one could argue that it’s already not HIPAA compliant…. but that’s a whole other post). The problem is that faxing is ubiquitous in healthcare today and the industry simply cannot survive without it. As soon as the Direct community resolves the “HISP trust issues”, all of the pilot programs will quickly become connected and natural pressures of competition (not to mention Meaningful Use) will cause Direct Messaging capabilities to spread like wild-fire. Once there is a reliable, national network for securely exchanging PHI, non-secure methods like faxing will fade away for good.

For more information on the Direct project, check out the wiki.

For information on how to get started, check out the Reference Implementation Workgroup