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.