Lightweight Scheduling

We are easy-going travelers. Not for us, the detailed checklists of places to visit, vineyards to taste wine in, or “happening places” to dine at, or “recommended bars to hop”. Instead, our travels are adorned with the fruits of serendipitous discovery and the surprise and delight that comes from having no expectations. And there have been no shortage of those.

A while ago, we stopped in Singapore briefly with no set plans other than staying at the Imperial Hotel and taking the free standard half day tour around Singapore that Singapore airlines offered. We managed to later see Serangoon Road, eat at one of the Indian establishments, take the sky lift to Sentosa Island from the World Trade Center, spend a little time in the Singapore Zoo, shop for T shirts with the transit system commuters at the Ang Mo Kio terminus, and shop and eat at Orchard Road. We later walked down to the Mariyamma temple at the base of the hill where our hotel was located. All in all, a memorable vacation that stills persists as fond memories more than 15 years later.

Another trip, we stopped at Zurich with three days of vacation, stayed in a Gasthaus by the banks of Lake Zurich (Zurichsee) and drove to St. Gallen, saw the cathedral and walked down the quaint streets looking at the shops and ornate 300 year old balconies of solid hewn wood, went to the monastery and then shopped and ate at a local departmental store cafeteria and watched the solid Swiss citizens shop, eat and walk around. We then drove through Austria and into Germany, along the banks of Lake Constance (Bodensee) and picnicked in the city of Lindau by the castle on the banks of Bodensee. We then drove towards Munich and stopped off for the night at a Gasthaus in a little village along the autobahn. Nobody spoke English, but we managed to communicate with each other, nevertheless.

We went on to see the harrowing sights at the Dachau concentration camp near Munich and the famed BMW auto museum in Munich. We came back by way of Neuschwanstein and Schwangau and saw Mad Ludwig's castle and the turrets poking through the clouds and rain. We even walked up the hill with hastily bought rain ponchos negotiating miles and miles of wet and runny horse scheiss as we trudged up the carriage infested road to the castle entrance only to find a long queue of tourists waiting to get in!

I’d like to think that we are not unplanned travelers in toto, but rather light-weight schedulers. We tend to make spot decisions on the time remaining, resources available and the potential enjoyment factor of visiting places. We also tend to adapt our plans to our state of tiredness, and continuing or lack of continuing enjoyment. As a result we have hugely enjoyed our travels within the US, and around the world.

This brings me to the subject of project planning in the IT world or in general for any type of endeavor. Consider:

• Software development is a response to needs caused by changes in business, environment, technology, market preferences, competitive pressures and needs for continuous improvement.


• These drivers result in the creation of plans.


• Plans result in the creation of budget items


• Approved budget items result in contracts and projects


• Contracts and Projects drive software development


• Software Development must be followed by deployment.


• Deployment is followed by use.


• Use determines the degree of success of the response to the original need.

Each of these steps takes non-zero time. And as the gears start grinding slowly, the original needs may start shifting or new needs may spring up not to replace the old, but to supplement the old. This is somewhat analogous to the situation when you are still in the process of reading this week’s TIME magazine and the next week’s issue comes in. You have now increased your reading load. But given your history with not completing the first issue, you can bet the second issue will also go unread or partially read. As the issues start piling up, reading all of them is impossible. This is exactly similar to the mess we call the IT backlog.

And not for small reason, long projects, slow budget decisions, lethargic or elaborate planning, waterfall development of software, and distributed individual machine deployments have all contributed to the mess.

Is it possible to apply lightweight scheduling to projects and let the projects drive what they can achieve, concentrating on speed and end results? And figuratively discarding unread, all those issues of TIME we never read or will never read…

Over time, we as a family have readily embraced the Internet, and now my smart phone, as tools to improve our lightweight scheduling as demonstrated by our recent three day trip to New York City where we walked across the East River on the Brooklyn Bridge, ate at Grimaldi’s Pizzeria under the bridge, took the Staten Island Ferry to Staten Island, visited the NY Transit Museum in Brooklyn, walked around Times Square around midnight, went around Battery Park, completed a campus visit of Columbia University, ate in Little Italy in Mulberry Street, and took the tram over to Roosevelt Island as well.

The judicious use of available information coupled with a light-weight non-bureaucratic attitude and extreme familiarity with planning, budgeting, requirements gathering, development and deployment may result in “Mini-Projects” that are three months in duration but put a permanent dent in backlogs.. A dream or a possibility? Or simply a great business opportunity for the right entrepreneur?

Agile Furniture Development

I just finished erecting a few non-trivial pieces of furniture in my daughter’s bedroom. She had been asking for new furniture, for a while, and I had been dragging my feet, dreading the inevitable complexity of (i) assembling an order of furniture from catalog piece parts that represented both a complete and aesthetic solution (2) lugging back 8-10 heavy boxes from IKEA (3) staging the boxes in some place other than the small bedroom and (4) assembling the furniture with the risk of broken parts, missing parts, thumb injuries and bleeding fingers from turning knurled nuts onto reluctant screws. But the fact of the matter is that my daughter is leaving for college next September and this is the last year she will enjoy her bedroom as a permanent resident of the Rao home. There was clearly a time WINDOW for her requirements, after which the purpose of the furniture was moot. We were all aware of impending changes to the situation, her needs and the context come August 2010.

It was time for agile furniture development.

With help from my father-in-law and a very close young friend of ours who is also mechanically inclined and adept, we set about the tasks of providing and installing furniture from IKEA in my daughter’s bedroom in a three day time frame. My daughter, busy with schoolwork, could not come to the store to select the furniture. We made phone calls from IKEA to my daughter to get course corrections on our choices of furniture and determine what attributes were not negotiable – the bookcase HAD to have glass doors, for instance. We brought the boxes back, laid them down in our foyer, and set to work with the assembly – a process that lasted two evenings, well, late into the night.

At the end of the effort, when my daughter finally came into her room, she could not control her joy. The room looked airy and spacious and there was light and style everywhere. In business terms, we had succeeded in “delighting the customer”. We had developed a solution within a requirements time window, incorporated needs that were explicitly discussed and exhibited competence and professional pride in executing the tasks that were undertaken.

The fact that more than 70% of IT projects come in dead on arrival, speaks to some deep flaw that is inherent within ourselves – we IT people. When contrasted with road projects that get built, and usually built well, bridges that are routinely constructed, train tracks that are routinely laid, and skyscrapers that shoot into the sky overnight, this IT project failure rate is incomprehensible to me.

I have a lot of suspicions and guesses for why this may be so. Other large undertakings like bridges, skyscrapers, railroad tracks have an already established base of knowledge that makes the planning simpler based on looking at past experience. Once they are commissioned, they move to completion with few dramatic changes but a lot of minor corrections along the way. Funding justification, once obtained, has to survive for the length of the project, for it to complete. The science and engineering is well understood. Meeting the expectations of the sponsor are fairly easy to test once the project is completed. And a number of these projects are either remodels or replacements for existing items.

There are two types of projects in the IT arena. Opportunistic software product development is based on an innovative idea taken to completion in the form of a software or hardware/software product that can be sold in a marketplace. This is the form of software development in the traditional Silicon Valley style startup. The other form is requirements driven software engineering – where the developer is coding to requirements provided by someone else – usually the business sponsor of the effort. The bulk of IT shops that support business and industry, fall into the second category and these are the ones that have demonstrated a 70% project failure rate.


In the IT arena, what we construct is based on requirements. And requirements come from the business. Business changes, often frequently, so requirements must necessarily change. When requirements change, work previously completed may have to be scrapped and new budget allocations are required to staff the changes. When this budget allocation does not appear, we have the classic IT backlog – a number of planned changes on a back burner.

Given that business change is inevitable, the expectation that IT requirements never change is both unrealistic and simplistic. IT development has therefore shifted from building “monument” style IT solutions to quick and dirty “beach-house” releases that address the requirements of the day, knowing that these will change and parts of the solution must be thrown away.

The move to agile development is partially based on delivering IT solutions within a narrow time window when the requirements are still relevant. The use of centralized deployment using web based solutions is to further decrease the latency between the availability of a solution and its deployment to end users.


I was reading an interesting article in CIO magazine http://www.cio.com/article/502263/Project_Management_How_IT_and_Business_Relationships_Shape_Success?source=CIONLE_nlt_projmgmt_2009-09-24 where a project team was able to accomplish much by close coordination between the business and IT staff. The thesis was “Bad relationships, are a leading cause of project failure”.

I quote and partially paraphrase from that article ….

The impact good and bad relationships have on projects is clear: "Negative relationships make people want to avoid each other or work against each other," says Bill Hagerup, a senior consultant with Ouellette & Associates, a IT leadership and project management consultancy.

On the other hand, when mutual trust exists between IT project managers and stakeholders, IT project managers are more likely to discuss problems that could threaten the project as they arise, says Imholz. If bad blood exists between the two groups, project managers may not be inclined to point out those issues, or they may try to cover them up.

If you look at projects that fail, invariably someone on those projects knew things were going bad," says Imholz. "If you don't have relationships and trust, those things don't surface. And when you don't do something about problems in a timely manner, those problems invariably get bigger. In many cases, minor problems become more serious because they're not addressed in a timely manner. A culture of openness is absolutely essential to good project performance."

Decisions affecting the project also get made more promptly when everyone involved gets along. "Fast and good decisions are crucial to keeping projects on track," says Imholz. "The failure of senior people to make decisions means decisions are made at lower levels of the organization. If you have a software developer who's waiting [for a decision] on a business requirement, there are three things that can happen:

1. He can guess what to do and guess right.
2. He can wait for a decision and while he's waiting he's not as productive.
3. Third, he can guess and guess wrong.

If those are three equal possibilities, two-thirds of the time it will be detrimental to the project. And if you stack enough of those decisions on top of each other, it will negatively impact the project."

The article goes on to speculate whether the background of IT personnel prevents them from recognizing the value of relationships and focus instead on the value of tools and processes.

"As IT professionals, we're raised on technology," says Ouellette & Associates' Hagerup. "Almost all the training we get throughout the years is about tools and processes."

Consequently, he adds, IT professionals think process and technology is the answer to everything, including effective project management. While project management frameworks and tools certainly help, projects are fundamentally people-driven, he says.

Agile development coupled with strong relationships can result in customer delight!

ATP Rankings and Bad Marriages

As the years lend clarity to events gone by, I begin to wonder… Are we reducing what are legitimately long term processes into events that are short-lived and wonder why the longer term processes whose outcomes we so desire are seldom successful.

Case in point: Marriage. (Apart from the exceedingly wealthy) the inordinate attention we pay to the event of the wedding is often detrimental to the later success of the marriage. The tremendous amounts of money spent on something that happens briefly instead of husbanding the money for the couple’s future challenges is the reason for a lot of stress downstream and must definitely contribute to the ultimate 50% divorce rate we have in this country.

I just came back from visiting the US Tennis Association’s US Open held in Flushing, New York. Over the years, we have found that the grounds passes bought a week into the tournament work for us – we get to see one or more sets of different matches, walk around the grounds and see the major players at very close quarters instead of sitting in nose-bleed seats at the Arthur Ashe Stadium with the price of the tickets we can afford and watching the players like ants moving around the court.

As I watched the top 20 players of the world play in various matches, it was clear that talent, practice and enthusiasm for the game was evident in all of them. Any one of these could have won the US Open on a good day. Yes, a good day or a bad day determines whether someone takes home a million dollars or not. We have reduced the years of practice, skill building, and sheer expertise into a one event horse race, however long and grueling that event is. Of course, measures like the ATP rankings have come into existence to winnow out the one trick ponies.

As a senior in high school, my daughter is seeking admission to college next year. As I step back and see the obsession of the students and the colleges with the SAT or ACT scores – a measurement taken on one day in their lives, their four years of high school achievements mean nothing if they do not make the high SAT minimum score cut because consideration of the high school performance comes second to the SAT.

And then we come to enterprise architecture. Almost always, the act of building architectures to understand complexity, deal with ever-changing internal and external environments, make sense of the business, systems and technology context – always a hard and time consuming exercise – is reduced to the exercise of passing a budget decision point event. We are transforming architecting and engineering exercises into a budget justification exercise.

For us to make lasting progress we must take the eye off the event and put it in perspective – a long term process is a succession of many successful events. As the successful general knows, “winning a battle” is not “winning the war”. In architecture terms, we must shift our focus from preparing for events to preparing and executing successful processes.

For enterprise architects, ATP like rankings are probably what the industry needs to regulate the skill and proficiency level of the practitioners!!

Can Enterprise Architects Be Young?

The other day, I was following a discussion on one of the enterprise architecture social networks I enjoy following, and the question came up:

Can Enterprise Architects Be Young?

Being a 55 + graying enterprise architect myself, and having seen the size and complexity of the beast at close quarters, I had to scratch my head to come up with a balanced answer and not resort to the usual, "Age is good when the going gets tough" argument.

You see, enterprise architecture is a little different from building that blockbuster product that sold a million copies or taking a company public in two years and then the company goes on to become the next Google. Those are very laudable achievements and have made their achievers both rich and famous.

To mix metaphors, if you pull out all the really big home runs out of the "success" equation, (because those very founders will tell you that a number of unknown and unpredictable circumstances conspired to provide the "win"), predictable success and predictable survival usually falls on the shoulder of the graybeards - be they valiantly paddling behind the poster boy CEO, or standing up in front like John Chambers, or Meg Whitfield. They are the ones with mortgages to pay, children to send to college and imbued with a strong sense of loyalty and duty to their organizations and people.

My response was, therefore:

It's not age that is an asset but the ability to have accumulated and learnt from a variety of broad AND deep experiences - which unfortunately doesn't happen overnight. It's also from having practiced incessantly as the recent book, "Outliers" so ably asserts.

Patients who are looking to pick surgeons tend to pick those with the maximum number of successful surgeries behind them. Perfect practice is a safeguard against risk. With all the exactness of surgery and modern equipment, the surgeon is still a key part of the success formula.

On the other hand, the ability to take astounding risks and succeed is a attribute of the young! As is the ability to dismiss conventional thinking and come up with innovative solutions. The ability to take exceeding risk is usually coupled with the inability to see or comprehend dire consequences. That's why young people have no problem taking risks!

Risks pan out -- sometimes. Any habitual risktaking, for it to succeed, requires pondering on probabilities of success, downside mess etc. and playing the odds and steering middle courses. Enterprise architecture, in my opinion falls into the surgery category and the habitual risk managing category. This is where a single home run will not work in a series that goes on forever.

A one trick pony cannot cover the breadth of knowledge, skills and experiences needed to understand, assimilate, aggregate, arrange, assemble, disseminate, communicate, propagate and evangelize - these are experiences that are accumulated over many jobs, many corporations, many setbacks, many varieties of tasks by a person who is driven by passion, curiosity, puzzles and quickness of mind - a true enterprise architect.

Ultimately when the messes from too many risks gone bad happen, as they usually do, it's always the adults cleaning up after the children have left.