Project Delta: web-based but standalone app

The vision for Project Delta (mentioned in this previous blog entry) is that it will be used by physicians who are also digital nomads (ie, sometimes they're working online, sometimes they're not). This means:

• Delta needs to act as a standalone app when the doctor is disconnected from the network.
• When there is a network connection, Delta acts as a web application that syncs its data over the network.

It's also important to state here that we decided this app would be built on RoR (Ruby on Rails). We want to benefit from the RoR's strength for supporting rapid and flexible development. But RoR brings one disadvantage -- it's still a pain to install on Windows (and some of our intended users may be Windows users).

Mulling these over, I formed early ideas about the technical solution. But I am aware that others are much better and more experienced than me on this one, so I asked my panel of technical advisors about this.

Here's the summary, which is good enough to go on:

• For a quick installer for Windows, try RailsFTW by Brian Bibat. 
• Stack Overflow discussion thread about distributing RoR apps as standalone apps.
• Essential tools for Mac Ruby developers is self-explanatory. Some of the tools are not that important in my opinion, but it's a good list to start.

If you know a good solution for our technical issues and requirements, do send me a comment. Will highly appreciate it. 

5 Important benefits of Scrum and Agile

I have been helping a small-sized government agency (let's call it Agency Pi) to improve its IT services. Management wanted the IT section to be more responsive to the information needs of the agency, which feeds into policy formulation which in turn helps create more intelligent decisions. That of course is the vision.

The IT section was not built for that new vision, so I was tapped to help make the transition. I decided to introduce Scrum and Agile software development methodologies to the organization. Note that we did not just introduce Scrum to the IT section, but to the whole organization. The way we introduced Scrum is a separate story in itself, so I'll leave this for another blog entry.

For this blog entry, I want to write about the benefits Agency Pi gained from this change effort. We could sum them up to the following:

1. More customer-centered development. 

Scrum puts the customer (represented by the Product Owner) in the center of development. Programmers often snubs customers, treating them as clueless clients. The important change here was to convince everyone that the Product Owner (PO) should have more involvement and a strong voice in defining the product, the development timeline and the team priorities. 

This is contradictory to traditional project management principles, where it's mostly the PM who decides on the schedule and priorities (in "consultation" with the customer).

2. Improved customer involvement in product development. 

The IT section catered to internal customers, usually heads of departments in Agency Pi who were dissatisfied at the inflexibility of the IT staff in responding to change requests. In my observations of the organization, it became obvious that Pi had what I call managementitis.

Managementitis assumes that software developers can easily predict what the customers want and could build a solution with minimal customer collaboration. Managementitis is a flavor of delegation by abdication. That is, after giving instructions, customers can forget about the project and come back at deadline time to see the magical software that the team developed without customer involvement.

To change this mindset, we enforce the requirement that customers should assign a "full-time" product owner (PO) in the project. This PO will make important decisions that contribute to the design of the software. We also require the customers to attend the regular product reviews (we made some mistakes here, but that's for another blog) so there are no surprises.

3. Team mindset that embraces change. 

A more difficult challenge was convincing the programmers to welcome changes requested by customers. The developers are used to the waterfall approach -- hammer out all the details in the design phase, get signoff, and build the software. 

In my experience, this way of building software is inflexible, resulting to programmers who stop listening to customer change requests, and high customer dissatisfaction. I still see this tendency in the programmers, but when I see it resurfacing, I just repeat the message that "Let's accept the reality that our customers will always want to change a feature especially because what we're creating here is new to most of us."

4. More balanced leverage for negotiation between customers and developers. 

The old mindset at Agency Pi promoted an adversarial relationship between customer and developer. For example, customers tended to demand unrealistic deadlines and then wanted programmers to commit and be accountable for the results. Sample dialogue: 

Manager/customer: "I want this very important database system to support our Program Such-and-Such. I don't know what its features are yet, but I need it next week. You need to bear in mind that since we don't know its features, you should be prepared for changing requirements. But I still need it next week." 

Programmer: "Uhm, okay. (Scratching head and wanting to jump out of window.)

You could see where the dialogue above would be headed (hint: "Hell."). And this often happened at Agency Pi. Using Scrum, we started advocating for more customer involvement. More customer involvement through the PO meant giving the PO more insight into the complexity of development. We made the customers see that development was about managing time, effort, cost and quality. Managing time is of course an illusion -- so we simply adjust cost, effort and quality based on the time we have. This is a key paradigm shift that customers and even developers need to understand in Scrum.

To do this, we repeated key messages like "We are now more open to change requests, but please recognize that these changes impact on time and effort" and "We will respond to that request, by adding it to the next sprint -- we assume that you want this prioritized?" or variations of these messages. Many developers hate to repeat themselves. But when you're dealing with deeply embedded organizational behavior, repetition helps.

Moreover, the Scrum approach gives the power of making product decisions back to the customer/PO. This often produces amazing results. Customers are more conscientious in making change requests and are more willing to bargain one feature for a more important change request.   

5. Improved customer satisfaction.

Of course, doing all of the above have resulted to better relationships with the customers, and a better grasp of the internal development processes that are happening on the side of the programmers and on the side of customers. 

There is now also more dialog happening in the development team, which by the way now includes the customer as part of its members. The programmers feel more empowered because it is clear to them that their participation in decisions is only up to the technical aspect. Issues on prioritization and scheduling are left for the PO to decide.

7 things I like about School for Startups (Book Review)

As an entrepreneur and a teacher about entrepreneurship and business, I've read many books about  starting a business. School for Startups stands out among the rest of them. What I like about the book:

1. It emphasizes taking action immediately on your business ideas.
2. The authors promote the contrarian beliefs that (a) you don't need to take big risks to be an entrepreneur, (b) you don't need lots of money to start a business, (c) you don't need a big or cool or original idea to start a successful business. Based on my experience, I agree on all of these.
3. The book contains many real-life examples of people who started their own businesses with very little capital and using simple, even copied, business ideas. 
4. These examples inspire the reader to take action, as in, now.
5. The book eschews business plans and instead recommends to use your time more effectively by just trying to sell something and letting the market decide whether you've got a good business.
6. The authors have real startup experience.
7. What's more, they have taught classes that helped students to start new businesses. (In one class, they set up a business importing chairs from Pakistan and made a health profit out of that one-time business.)

The underlying themes of School for Startups is to take action, start small and start simply, persist and learn as you move along. If you've been mulling over starting your own business, this is the book I would recommend you read.

Highly Recommended:
School for Startups is by Jim Beach, Chris Hanks and David Beasley. Check it out at Amazon.

Two health information systems: Mu and Delta

I am excited to report that my team and I are slowly building a portfolio of health information systems. Our first major project in this growing sector was Project Mu (a codename, of course). Technically, Mu is a clinic information system -- it helps manage a chain of clinics with branches spread all over the Philippines. 

Mu contains software modules to record patient demographics and health records, including diagnoses and treatment histories. It also has a module to generate price quotations and record payments (stopping short of generating receipts -- the client recognized that we weren't building a POS or point of sale system). Mu's application and database are web-based and accessible through a private cloud. Mu was delivered and deployed last year and we are now in the process of enhancing it, based on customer requests. 

Our team is proud of Mu because our clients are happy with the product (in fact, they've been giving us repeat business). We also celebrate the fact that we completed this app despite overwhelming obstacles attached to the client's circumstances (details of which I could not reveal here -- suffice it to say we overcame great odds and still came out with a good product).

And now we have two more forays into health information systems. Of the two, I'd like to write here about Project Delta. The Delta system is now in its inception stage. Like Mu, Delta will contain modules for storing and retrieving patient data, recording doctor's notes, and generating treatment plans and recommendations for patients. I am not yet at liberty to reveal details, but I promise to blog about it as soon as I get clearance from my clients, who are doctor-specialists.

What is exciting about Delta is that it will support physician-specialists who are relatively mobile -- that is, doctors who run their practice in various clinics and hospitals in different locations. Imagine Dr. M. who brings a laptop to the clinic. When she sees a patient, Dr. M. records her findings in Delta running in her laptop. If there's an internet connection, the app will update the patient information stored in a cloud database server. There may also be an app for iPad or an Android tablet that would allow a doctor to view patient records and record some notes using that mobile device. 

Of course, this is the product vision for Delta. We won't necessarily deliver all of these at the start. Our cooperative customers understand the importance of iterative development and starting with simple features (a rarity in the IT industry). So our first sprint will be just about the basic patient data and the important data entry forms.

By the way, the second exciting feature of Delta is that we are developing this entirely from a scrum approach. Even more exciting is that we are using online tools to improve our virtual collaboration, not just for the development team, but also with our clients who, as I've mentioned, are mobile physicians. I'll be blogging more about the approaches and tools we're using to start up Project Delta.

Jeff Bezos on believing and persisting

In a previous post, we talked about two key starting points for change: belief and persistence. Forbes magazine recently came out with an insightful piece about how Amazon.com grew to become the giant that is is today.

Bezos: [...] Our first shareholder letter, in 1997, was entitled, “It’s all about the long term.” If everything you do needs to work on a three-year time horizon, then you’re competing against a lot of people. But if you’re willing to invest on a seven-year time horizon, you’re now competing against a fraction of those people, because very few companies are willing to do that. Just by lengthening the time horizon, you can engage in endeavors that you could never otherwise pursue. At Amazon we like things to work in five to seven years. We’re willing to plant seeds, let them grow—and we’re very stubborn. We say we’re stubborn on vision and flexible on details.

In some cases, things are inevitable. The hard part is that you don’t know how long it might take, but you know it will happen if you’re patient enough. Ebooks had to happen. Infrastructure web services had to happen. So you can do these things with conviction if you are long-term-oriented and patient.

Reading this excerpt made things click in my mind. If you're old enough to remember -- Amazon was in the red in its first 3 to 5 years. Despite this, Bezos persisted. Shareholders kept believing and investing in the store. Amazon kept wowing its customers even though they would lose money doing this. (I know some friends who got 2 copies of books they bought because the first shipment didn't arrive on time, so Amazon Fedexed replacement copies to rectify and then the first set of books arrived a week later). 


Just imagine. You're a fledgling company, you're losing money because you're not reaching the right  sales volume, and you insist on delivering great customer service at a loss. Most would have given up. Bezos believed and persisted and slowly, Amazon thrived. I especially like the last part of the excerpt on ebooks ("they had to happen" -- what faith this exhibits!). Bezos was ahead of his time and waited and waited and waited. 


To compare: as an IT businessman, I also saw that ebooks were coming (way back in 2001). So I made this proposal for an ebook store and sent it to some local book publishers and distributors I knew. They gave a lot of excuses. They hemmed and hawed. My faith on my proposal was weak and I threw away my proposal. Ten years later, I am buying ebooks. If I only persisted, I would have become a pioneer here in the Philippines. Today, I've made peace with this and treat it as an important lesson for me and my students in change management class.


If Amazon did not have a long-term vision in mind, and Bezos wasn't persistent, and his stakeholders weren't convinced of Amazon's long-term vision, then we wouldn't be seeing much of Amazon these days. I am thankful that Amazon and Bezos were stubborn. 


Read the full article on Bezos and Amazon here. 


Read the previous blog post titled "Believe and persist in your advocacy"

Believe and persist in your advocacy

All IT and software deployment projects are change management problems to solve. If you don't handle the change management aspect very well, your deployment will fail. 

* * * 

In my change management class (which we formally call Leading Organizational Change), I always emphasize that the first step in advocating for change is to first believe in that change. Have you encountered salespeople who tried to sell you something but didn't really know what they were talking about? They came across as insincere and nothing they said could sway you to believing them.

In the same manner, if you don't believe in the change you're pushing (it could be an IT solution like an intranet, an information system, or even a community effort like a school feeding program), your target audience (aka intended users or stakeholders) will sense your insincerity. You will come across as fake and you will blow your chances of making change happen.

On the contrary, when you believe in the project you are rolling out, you will have a genuine concern for people who are resisting your efforts. You will ask them why they are not buying into your effort and you will find ways to convince them about it.

I had an epiphany when I was considering switching to a Mac. For about 23 years, I have been a user and staunch defender of PCs and Microsoft. A Mac store attendant tried to convince me to switch. He asked me what was making me hesitate and I told him that I feared the Windows tools I was using (like MS Project and Visio), wouldn't be on the Mac. Without speaking a word, he activated BootCamp and started up Windows on a Macbook. That was my turning point. It started with a store attendant being genuinely concerned about my issues.

When you believe, you win over people. More importantly, you gain another strength as a change advocate: persistence. Persistence will help you survive through resistance and opposition. 

As the person leading change, you are put in a dangerous position. Heifetz and Linsky point out in the book Leadership on the Line that your opposition will try to use politics, seduction (offer you distractions to divert you from your advocacy), and character assassination against you and/or your project.

Once, a livid representative from a customer company threatened to kick our team out of a project (that's a different story to tell). Our team thought the customer company would benefit a lot by using a new but very flexible Technology X. We found out later that Livid Representative was leading an in-house development team who was creating a similar solution using Technology Z. They probably wanted to claim credit for discovering and creating the solution for the company. Hence he threatened to kick us out of the contract. Of course, our team stood down and grudgingly supported what the in-house team was doing (after all, we were only contractors). It was a clunky and dirty technology -- we knew because we had a taste of the power of Technology X.

We swallowed our pride, but we persisted in using and promoting Technology X. Years later, the company rehired our team to deploy exactly what we previously recommended to them. It turns out that the company grew dissatisfied with their in-house team and the Solution Z. Desperate, they hired an independent IT consultant who recommended -- guess what? -- Technology X.

We secretly gloated and we knew we wouldn't have reached this goal if we gave up that early.

First, get the process right

Instead of using IT to initiate change, focus on the process and people first. Put the customer at the center, reorient the processes to delight the customer, then create the IT system to support the improved processes. Managers and IT developers, take heed!

* * *

Here's one trick I've learned in developing an IT solution. First ask, what process is our IT solution going to enable or support? Then, we build the IT system to fit that process. I've found this to be very effective in increasing the chances of success. And by increasing chances of success I mean making the software really useful, enticing users to use the system and get attached to it.

After a couple of IT project failures, I reevaluated our development approach. We hinged our hopes on the thought that employees will use software because it will make their work easier. But most employees are not naturally techies at heart. Instead, they think, "New software = more work." I've seen this happen many times that I thought we should start approaching development in a different way.

To change the approach, simply reverse the premise and assume that employees are usually averse to technology solutions. This opens up a different development approach. It forces us to design and develop around the needs of actual users. It requires us to understand the work process that users and actors go through, and how our IT solution could facilitate that process. It also involves working more closely with the users/actors, which in turn brings more buy-in for the solution.

One of my earliest clients to agree to this approach did not take a lot of convincing. She knew that their different branches used different procedures to perform the same job. She saw the sense of first seeking to standardize the different office procedures before attempting an IT solution.

So first, we embarked on writing down the steps for each core process, noting the variations. Next, we took a look at their policies, guidelines, and legal documents to find the minimum requirements. Then we improved the procedures by asking the question, "What value does this procedure give to the office?" With this filter in place, we were able to remove non-value-adding steps, redundancies, and outdated activities in the process. We closely consulted the users/actors who were involved in the processes.

The result were improved office procedures that were leaner and faster. The manager issued a memo introducing the new, standardized procedures, and tied these to the incentives of branches. Hence the motivation for adapting the new procedures was not IT itself.

When time came to build the IT solution, we simply got the improved flowcharts and used them as bases for the software. And since we worked with the users/actors to define the new procedures, the people  saw how the IT component snapped in place to facilitate the new procedures. This in turn built more enthusiasm and anticipation for the coming of the new software.

In traditional IT development, we often neglected to focus on the processes and the value that these processes delivered to the office and the employees. But the revised development approach, we gain a new lens on managing an IT project -- one that allows us to focus on the things that matter and to treat the client as development partners.

This demonstrates how, in many cases, management complements IT. Management's strengths can make up for the shortcomings of IT,  and vice versa.


Related article: IT is not the solution.

IT is NOT the solution

I often preface my talks and lectures with this statement: "IT is not the solution."

After saying that, I can separate the veterans of IT projects from IT development newbies. The veterans will nod in agreement and the newbies frown at my puzzling statement.

Blame it on the phrase "IT solution" that the industry uses. The term tricks us into thinking that technology is the solution by itself. It is not. Information technology is only an enabler or facilitator of the real solution.  

I'll give an example. In one failed database project I've been asked to troubleshoot, the boss (let's call him Mr. A) expected that a document tracking system (let's abbreviate it to DTS) would solve the pesky problem of employees consistently misplacing important files. Yet, when the software was built the problem persisted. They even installed bar codes and scanners to make DTS more convenient to use.

Mr. A asked me if RFID (radio frequency identification) would help improve the DTS. Apparently, some vendor had approached their company and told them that bar codes are history. The real solution is RFID. Why? Bar codes need line of sight and people actually "shooting" a scanner on the bar code. RFID gets automatically detected without people having to do extra work. 

I interviewed him and his staff to find out more about the problem. What I found is that even if they had installed RFID, the real problem would still continue: employees did not buy into the value of tracking documents easily. And Mr. A never really understood that installing the DTS would need at least two factors:

1. A change in the office procedures to add a checkout step. ("Before you bring that file out, please sign the logbook.")
2. A records officer who would really do his job. ("Hey, where are you going with that file? Bring it here and sign the logbook.")

None of these steps require technology. They in fact require a change in staff behavior. And to change behavior, Mr. A needed to convince employees of the value of checking out a file.

Mr. A had too much faith in information technology and he thought installing the DTS and a nifty bar code or RFID system would automatically change the procedure. In reality, employees found it tedious to log the file they were borrowing for just a few minutes. By not seeing the big picture (ie, if we lose the important files, we lose time and money trying to hunt down where the files are currently located), the employees did not buy into the need for logging and tracking documents.

So remember: IT is NOT the solution. Remembering this will help you make your IT projects less prone to failure.

Change Management and IT

In IT, change management often means making the client go through bureaucratic hoops to slow down the change requests from the users. In my reckoning, a lot of times the change request system only worsened the situation: it led to the software developers feeling more powerful and the customer feeling more alienated from the development process, since the product ended up being the way the developer wanted it. This problem always bugged me. I tried to think of a different way to do change management, but the literature on this was all based on technical solutions (ie, creating procedures and forms to manage user expectations).

Years later, I would encounter the same phrase -- change management -- in MBA school. But the way it was tackled in business school used a different approach to it. The first principle they taught us about change management was: "You can't manage change."

That's because change is dependent upon the people involved in (affected by) the software development process and you can't manage (control) people the way we manage furniture, or printers, or office supplies for example. (And for that matter, can we even really manage how employees use office supplies and printers?) People are the X Factor of management. That's why business school distinguishes between managing and leading.

Managing is about seeing what we have, preserving status quo, and optimizing what we have. Leading is about seeing far ahead, seeing more than what we have, and guiding people towards that vision.

In their book Leadership on the Line, Ronald Heifetz and Martin Linsky argue that the usual management problems require technical solutions to solve, but change requires adaptive solutions. Technical solutions are those we do by the book or were taught to us in school or from the company manuals. Adaptive solutions are more challenging because they require us to understand the environment and experiment (ie, "to adapt").

Leading people through change is an adaptive skill. It is about knowing the people well and how to influence them towards a certain goal. It's not about position or authority. It's about selling a vision of change to the people affected by the change. It's about empathizing with those who stand to lose a lot from the change you are introducing. It's recognizing that they have emotional attachments to tightly held values and traditions about how they did things the old way and how that mattered to them.

Sounds crazy, right?

But think about it. All software development involves leading users through change, often difficult change ("What if I become redundant if this new computer system gets popular?"). But what is an IT expert's usual response to resistance to change? "Give them the right training and a user manual, and they'll stop resisting."

Training won't always work, because some users may be attached to one way of doing things ("My dad was an accountant for 50 years and he taught me how to do this in columnar pads."). And change always requires a learning curve that forces people to jump out of their comfort zones ("This is just more work for me.")

I've seen and heard all kinds of excuses and expressions of resistance. But most of them stem from the few patterns that I mentioned above (more of these signs of resistance in future posts). If you ask me the key to change management and resistance, my quick answer is "Plan and Persist." (And more about these, in future posts, too).

How about you? What signs of resistance have you seen and how did you work around them?

IT Management Lessons

I started working in the field of IT in 1987, teaching computers while studying at the University of the Philippines. Then, I became a desktop publication designer and eventually a web developer and software programmer. Now I run a consulting business that provides IT strategy advise and software development.

I have picked up many lessons along the way: on things that work and things that don't in software development, in running a business, and in developing an IT strategy and plan. My goal for writing this blog is to help others avoid the mistakes I made, and to start the dialogue on how to change the IT landscape. I want us to look at the way we do things and ask ourselves how we could make them better.

Much has changed in the field of IT and its customers. In the early days, IT resembled more of a religion. Practitioners -- analysts, programmers, and system administrators --  were the only ones who knew the truth. Mere mortals (aka the users) had to grovel and please the gods in order to get assistance. And if users were not worthy enough, they deserved wrath and punishment.

Here's one hint about the old world order in IT. When the internet began to boom in the mid-1990s, system administrators traded anecdotes about stupid customers, like the ones who forgot to turn the power switch on, or the ones who didn't have a modem but still tried to dialup. I am guilty of trading those stories too, since I personally encountered them.

Today, in a very competitive market, customers have become more demanding. They have more power. Because there is more competition, customers could switch to the competition more easily. In the Philippines, Manila developers compete not only with Indian developers, for example, but also with developers in the provinces.

Non-IT businesses have realized that in this arena, what will set them apart is to offer better customer service and better products. IT businesses, however, are only belatedly and begrudgingly acknowledging this new competitive environment. The result is that we still run in an environment and create products that are:

• Not user-centric.
• Averse to communicating and building a relationship with customers.
• Inflexible to change.
• Promise too much but unable to meet actual requirements.
• Often delayed and costly.

We want to keep the illusion that IT experts can never wrong or can never fail. This causes a lot of stress. But the more damaging result is a shared sentiment among our customers that IT practitioners are not reliable and are overpaid arrogant bastards.

For a period of time, I thought that only I felt the same way about my field. And then I read about the interview of ArsDigita founder Philip Greenspun (Founders at Work), who also complained about the arrogance and lack of customer-focus among software developers. Greenspun asserted that real engineers (ie, civil and electrical) talked to their clients and involved them to create solutions that solved the real problems of the customers. That's a far cry from what's happening to the IT industry today.

Creating change in the IT industry will take a lot of work and a lot of re-examination of ourselves, our attitudes, and our behavior. I believe we can do it, partly because I've worked with and met many IT people whose mindset and behavior prove that there is hope.