Implementing Human Services Software in Moldova

Moldova, the Country of the recent “Twitter Revolution” is often referred to as the poorest country in Europe.  I am spending the week back in Chisinau, the capital city, where I have been several times over the past few years.  There Keystone Human Services International  has a small office and a staff of about ten people who are supporting several projects.

I am here with two colleagues from the US to implement Social Solution’s  newly acquired software TOTAL: Record, and despite the language differences (Romanian is spoken in Moldova) and despite the differences in human service systems models, I am delighted to report that the implementation is going very well.  As I mentioned in earlier posts, leadership is very important, and in accordance with that reality, I have travelled here with the CEO of Keystone Human Services International.  As in all implementations, that makes all the difference.

Strictly as an aside. Social Solutions refers to TOTAL:Record as “financial performance management” software for human services organizations.  In another post I’ll write about how they are seriously under-estimating the software product they acquired, but I’ll save that for tomorrow, I promise.  Suffice it to say that we are implementing it in Moldova, where medicaid reimbursement rules are not a driving factor. to say the least!

We are deep in the detailed struggles of all implementations—-how to define fields, activities, costs, etc.  It is the task of turning diffuse programmatic activities of helping people achieve full active lives in the community (rather than in institutions) into the bits and bytes of reportable data—-ie.  information.  I love this stuff!

This is a particularly fun project to be on—I am not usually so deep in the details of our software implementations anymore.  This one, though, will serve as a model and an inreplaceable information source for what we hope will be many more projects, so I am bringing in the most experienced staff and the most talented software application experst we have—under my watchful eye.  It’s good to be reminded how important valid and reliable information regarding human services can be; and good to be reminded of how rare it is.  I feel privileged to be doing this work.

 

Preventing Project Meltdown 101

 9 RULES FOR PREVENTING PROJECT MELTDOWN 

 

1.  Know what the project is supposed to accomplish.  This may seem obvious, but, trust me, people often have very different ideas about the goals, and then have very different yardsticks for measuring success.  Get everyone on the same page.

2.  Get the team together.  When I say in #1 that everyone needs to be on the same page, make sure you know who “everyone” is.  Name names.  Set aside a specific space for the team to meet regularly, and make sure they have the resources to complete their assignments.

3.  Name a steering committee.  Every project has more than one stakeholder, and each primary stakeholder needs a presence on a project steering committee.  The steering committee is there as a backstop to keep the project from veering off-course—don’t let it get bogged down in decisions that the project team should be making.  Keep it focused on strategic issues and on smoothing the path for the team.  The steering committee is the place for decisions and questions that the project team can’t answer or solve on their own.

4.  Keep the steering committee as small and as senior as possible.   Whenever possible, the CEO should lead the steering committee.  That way, in the unlikely event that the steering committee can’t reach a decision by consensus, the CEO is there to make the call.  Needless to say, once the decision has been made and communicated to the team, all steering committee members should support it.

5.  Set realistic deadlines.  Projects that have unrealistically tight deadlines often lead to burnout and staff turnover.  Conversely, deadlines that are too loose or too far in the future lead to a lack of project focus.  These are the projects most at risk of never reaching completion.

6.  Celebrate success along the way.  IT projects are hard, and in human services organizations we usually don’t relieve the team members of their other full-time responsibilities.  Remember to thank them and to celebrate the victories.

7.  Work through the challenges.  There will inevitable be surprises and challenges along the way.  Keep a level head, be flexible, and don’t panic.  There is always a strategy to success.

8.  Be attuned to the natural rhythm of projects.  They start with enthusiasm, quickly move to steady state, and then, critically, move to a period of anxiety as the deadline or “go-live” date approaches.  Be sensitive to where your team is on the time-line and support them appropriately.  Be cautious when they are exuberant; be a cheering section during the steady-state period; be attentive and encouraging during the anxious times; and, celebrate with them when the project succeeds.

9.  Align the project with the strategic and operational goals of the company.  Your team needs to know that all of their hard work moves the organization forward in an important way.  Remind them that even if they are working on implementing a work-flow project in the human resources department, it has an impact on the lives of the people served in your agency.

 

More about the CEO

I found myself discussing software implementation strategies with colleagues  today, and a question was posed to me about a stalled project at an organization we’re familiar with.  The project has been stalled for quite a while, and even the predictable flared tempers are starting to die down.  The project appears to be on a long slow death march, according to some insightful observers.

I don’t necessarily agree.  I’ve seen more moribund projects than this one be revived and become successful generators of organizational ROI.  For me, the key is the perspective of the person at the top.  If that person still believes in the strategic and operational value of the project, and if the technology tool is viable, then the project can be saved.  If the person at the top has lost interest, or never had it in the first place, then everyone should pack up and go home. 

It really comes down to leadership and whether the CEO is willing or capable of exercising it.  It’s that simple.  A strategic software implementation in a human services nonprofit is an exercise in and a committment to an overhaul of tired business processes, to a reorganization of duties, and to a new way of measuring success.  CEOs need to be prepared for the inevitable grumbling they will hear along the way.

This isn’t unique to human services organizations—every enterprise implementation faces those challenges.  What’s a little different for those of us in the human services’ world is that our organizations in general haven’t developed much sophistication around technology.  I often see the extremes of a culture that shuns technology and whose employees don’t know how to use a computer and a culture of thinking that  clicking the “install” button on shiny new software will solve all organizational ills, living side by side in the same agency.  The CEO has got to step up.

So, to all my CEO readers, take a deep breath and own the technology plan for your agency.  It’s a great way to get to know your company all over again.

tomorrow’s post will be on preventing project near-death experiences.

 

The technology role of the CEO or Executive Director

I’ve gotten some off-line feedback from CEOs on my last post, “it starts at the top.”  I’ve heard that many CEO’s want to use technology strategically, but they don’t know how to translate that into action.  

This post will be about the role of the CEO relative to technology.  The CEO needs to have the vision of what information and communication can do for their agency, and how it promotes the agency’s strategic vision.  If you’re a CEO and don’t already have that view of your agency, here’s how to get it.

Start first with your strategic vision for your organization, and with your mission statement.  For example, my organization, Keystone Human Services, has a mission statement that includes the following: Create opportunities for growth and meaningful life choices so that all people can be valued, contributing members of their community.  That mission statement is broad enough to encompass many areas of service, but is grounded in the idea of the individual and the community.

That means, then, that everything the organization does, including technology, either contributes toward achieving that mission, or it should be re-evaluated.  

Practically speaking, that means that whenever your company is looking for ways to use technology, link it back to the mission.  My organization made a commitment a long time ago that every employee needed an email address and needed access to the Internet.  Well before this was accepted practice, we moved forward with this vision, because our mission is community-based.  The “community” is not just the physical community we can touch, it is also the “virtual” community created on the web.  The mission guided us toward the practical technology action we needed to take.

Then the CEO, knowing that this direction would encounter some internal resistance, asked for monthly reports of how we were doing, started sending regular email updates to employees, and started using the tool he wanted others to use.  This led to the culture change we were looking for, and set the stage for the use of other tools.  We still have a long way to go, but our employees know where we are heading.

If you’re a CEO and your organization isn’t using technology as strategically as you would like, get together with your IT leader(s) and talk about what’s holding you back.  If you start at the top, keep it grounded in the mission, and use the tools you want others to use, then you’re on your way.

 

It starts at the top

  All successful technology implementation projects start with the CEO or Executive Director.  In many Human Services organizations (HSO’s), that will come as news to the CEO, and in some cases, it’s news to the IT Director (if there is one.)  But it’s an important guideline that often is the difference between success and failure.

I’ve been talking with a nonprofit HSO CEO for several months as we worked together on a local effort.  His organization is stuck in technology project, and his agency is not alone.  I could be writing about at least ten different organizations I work with, and many of you will recognize the problem.  Too many nonprofits have been there. 

The agency has been trying to implement new software for over a year, and are still in the early stages of the project.  The CEO honestly believes it’s the vendor’s fault, because that’s what his IT staff is telling him.  He’s very frustrated and even angry at times, because he did so many things right.  He set the right tone–one of efficiency gains, and cash flow improvement, he helped select a forward-thinking vendor, and he empowered his people to go make it happen.  He was very supportive every step of the way, and then he stepped back to watch the progress.

So, what went wrong?

What he did do, was great.  What he didn’t do, though, helped sink the project.  He didn’t stay involved.  He didn’t ask for routine updates on the status.  He didn’t establish a mechanism for resolving internal disputes about process improvement.  He CEO let change-averse technicians undermine the project, and he’s relying on them to explain why it’s a year behind schedule.  Not surprisingly, they blame the software company. 

CEO’s must stay engaged in technology implementations.  They don’t need to attend every meeting, or stay on top of the thousands of details, but they need to stay interested.   The CEO sends a thousand signals every day about what’s important to the company, and what’s important is what s/he is talking about and asking about.  The standard project management tool of keeping the “executive sponsor” fully informed and engaged, is critical to keeping a project on track.  That’s why the software company is not blameless here either—they clearly didn’t do a good job with expectation setting, with communication, with project management or with change management.   They didn’t even get the fit/gap analysis right.

 With leadership from the two CEO’s, both from the HSO and the software company, the situation can still be turned around.   Two wiser, more successful organizations will be the result.

Success starts at the top.