Strategic Programming

My time here is rapidly winding down, and by the time you're reading this entry, there'll be only one week of work time before I head to Jaipur, Mumbai, and the mysterious land called America. (I've found myself actually wandering through Pittsburgh streets on Google Maps just to remind myself what home looks like.) The nature of my work in these past few weeks (basically, since about 1st April) has really changed. As you might remember, when I first came here, a lot of what I was doing was data analysis and just trying to get a handle on where the project was overall. Once I realized the level of corruption/error in the data, it turned into an extended effort to just get the fundamentals ironed out. Over the final week or two of March, that's started to sort itself out. The female health workers are almost getting the hang of the surveying, we've gotten data entry up to a reasonable speed[1], and they've hired a new statistician who's helped a lot from an analysis perspective. They're also expecting him to take over as boss, so I'm deliberately turning over to him much of the work I'd otherwise do.

So, if some of my problems are solved and the rest are now in someone else's job description, what does that leave me? Conveniently, our friends at the Harvard Business Review decided to publish an article that advised CEOs to focus on the work only they can do. Having reflected on that, the work that only I can do is something vaguely resembling strategic planning. PS Reddy is now in America, and even though he knows the Hyderabad project well, he's not intimately familiar with the organization or the technology. Dr. Ashok knows the organization, but not the technology or what it's capable of. The staff here know the technology, but visionary thinking is not a common product of Indian higher education.

Thus, I've spent the past 1.5 weeks and will spend the next 1.5 weeks working primarily on laying out a vision for REACH: where is it going to go in the next year or so? I'll share some of those ideas in another post, as they're still being run up the chain of command for feedback. It turns out, though, that what I'm doing is not so much strategic planning as it is "strategic programming". This organization has turnover. A LOT of turnover. As in, my project alone has lost three and gained three staff in my two months, and it's a three-person project. (Thankfully, one of the three positions turned over twice, so I still have one original.) This means that I can't depend on whoever's reading my plan to know anything at all about the project. That, in turn, means that I don't get to just paint with broad brush strokes; I fill in all the little details.

I've said to some of you that this project like using human beings to do computation -- that wasn't entirely a joke. It really does feel a lot like programming, albeit with a serious latency. I have to build detailed lists of everything I want to see happen in the next year, think of all the ways in which someone might do it incorrectly, and then write down instructions to prevent that. The planning document for starting REACH in the next district over is eighteen pages long, and there'll be another document (not quite so long) for continued operations in this district. Reading it would cure any insomniac. It's a semi-futile exercise, since there'll still be mistakes made, but at least they won't be the same mistakes we made here.

---

[1] By hiring double the number of operators we need at steady-state, which has now left us with an unfortunate quandary. More on that in another post.