Types of Projects

This is an attempt to classify different types of IT projects that happen on the Street.

1) Projects that are demanded by stakeholders: perhaps to support a new business or for regulatory/auditing purposes, etc).

Basically the business is hot for these projects. They demand them to be highest priority. These projects are necessarily agile and driven by stakeholders. Delivery is so tight and fast that stakeholders may even go straight to developers to discuss their needs. A BA may or may not be involved.

The pros:

• Gives the users exactly what they want, no more and no less
• Business feels IT is responsive to their needs

The cons:

• Business babble <-> Techno babble translation process (without a BA) may have some glitches, but feedback is fast and there is far less opportunity to go astray and deliver unneeded functionality
• Sometimes IT may run into a business user who dictates the technological solution rather than just give requirements. And who might also quickly and violently change requirements. In this case, it might be very hard for IT to push-back. One strategy that is being implemented in just such a case is to have the business user deliver his requests in batches. Anything making a certain cutoff time will be implemented and anything afterwards will make it in the next day. Another strategy is for IT to "cost" the list of remaining work items [i.e., Item 1 will take 3 hours, Item 2 will take 4 hours, etc] and have the Business User prioritize them himself. He'll know exactly what he's getting and when. He might even slow his requests down :)
  

2) Strategic Projects driven by IT

The way IT implements strategic solutions is long and cumbersome, falling back on a waterfall, BRUF (Big Requirements Up Front) approach. Stakeholders don't see value and in the interim, come back with more tactical projects that drive project plans and resources off-course. This type of project needs strong motivation and vision in IT. The initiative for this is most likely spawned by IT and sold to the business as a 'game-changer'. The threat here comes from being derailed by stakeholder demands for other projects (either because some other requirements arise or because they haven't seen any value come from the time/money spent so far).

The BRUF/Waterfall method is especially a threat to these IT driven strategic projects because of IT's tendency to want to do it right the first time. Months may go by without the stakeholders seeing a single screen and giving their feedback on the direction of the project. Without something tangible to go back to the business with to elicit real feedback, the development team may dream up something that is completely orthogonal or irrelevant to what is actually needed by end-users.

And when the system is actually delivered (most likely many, many months later), enthusiasm has waned and the system is so off-base from what was sold to the stakeholders that it is deemed un-usable or obsolete.

The biggest impediment to these types of projects is lack of stakeholder participation. Steps to combat this are:
1) Decrease time between 'selling the system to stakeholders' and delivery of a working system (even if its initial feature-set is limited)

2) Iterative Development and prototyping and involving stakeholders at each and every stage.

Why, oh why, Waterfall?

Many of the projects in IT on Wall Street don't seem like they're developed 'agile-ly'. PMs, BAs and developers still have waterfall ideas in mind.

This goes against all common sense: (1) It is well documented that the waterfall system is an extremely poor approach to developing useful systems to stakeholders, and (2) in an arena like Investment Banking, where Time to Market is usually "need to have it yesterday", waterfall is completely the wrong way to go.

There's something about the human psyche that gravitates towards using a waterfall approach: possibly the desire to have things wrapped in packages with a bowtie so that it can be deemed complete. I'll complete the requirements, hand it over to the architect who will then complete the design and then hand it over to the developers who will then hand it over to QA. [QA of course gets short-shrift in all this].

Blame Henry Ford and his assembly-line :) Of course there's a huge difference between assembling a car (or any manufactured product) off the assembly line and developing software. By the time the car or toy or whatever product it is hits the assembly line, prototypes have been constructed already, focus groups have been interviewed, potential users have been approached, etc. Do we do this with software? I've seen it happen on projects where prototypes are not even created and shopped around to end users for their feedback.

The assembly line is just not the best analogy for building software...

The Nature of IT on Wall Street

It may seem business users are fickle, that they want and demand a system that does X, but then when it's delivered, they never use it. That could be attributed to a variety of reasons: (1) perhaps the requirements gathering exercise went awry (i.e., the system doesn't do what they wanted it to do), (2) usability is horrible, or (3) their needs have changed; possibly because the system took too long to deliver and they've adapted their business processes and need something new or even nothing at all.

The above are just a smattering of reasons, and definitely not all-encompassing. However, working on Wall Street (and I'm not talking just about IT) is a risky proposition. Talk to 1st year analysts about waste. These people sit on the front lines and put in 15 hour days and 90 hour weeks. Some of their tasks entail creating Powerpoint presentations, creating reports, binding books, etc. in painstaking detail and constant revision. And you know what? Sometimes, they're never even used. It's no wonder then that this 'waste' trickles over to the IT side. The business is apparently 'fickle' all on its own.

We in IT want to so desperately get it right. We want to have perfect requirements, requirements that don't change, so we can move to design and then software construction without any hiccups. Change bothers us which is ironic because technology is all about change!

We want to manage projects in classic waterfall fashion where we're absolutely finished with requirements which we can then hand over to our architects who will then create an architecture/design which can then be handed over to developers and so on. Change disrupts this.

We need to get away from this line of thinking. We need to welcome change. We need to be adaptable. And if there's waste going on with our business users, it sure as hell is going to happen in IT. Denying this is futile. Waste WILL happen. But the term 'waste' is really a misnomer. It's not waste if it helps us move towards a goal. It's an avenue we explore but then realize that it's not the right one. That's what it really is.

Edison once said: I have not failed. I've just found 10,000 ways that won't work.

Case in point: I've heard that Apple creates zillions of prototypes and goes through very rigorous testing to ensure that only the highest quality product goes out (in terms of usability, customer appeal, design, etc). Would these zillions of prototypes be considered waste? Not when you consider what Apple has achieved! They are true innovators and it takes incredible zeal and innovation to get there. But also a freedom from the fear of not having to do it right the first time.

So those prototypes or that first release of the software that you don't want to develop until the requirements are fully in, forget it. Your best bet is to go ahead and develop it so you can use it to elicit even better requirements from your users and build relationships with your stakeholders.

More thoughts on Customer Service

When people jump up and down for you, cater to your needs, pay attention to you, drop what they're doing to attend to you, now that's customer service!

Ever encounter one of these cashiers at Target or Home Depot? How they take their own sweet time to even look at you when you come up to their counter? And make it seem like they're doing you a favor by even talking to you. That's anti customer-service!

When a person makes you feel excited and welcome for doing business with them and even interacting with them (when you might not even buy anything from them at that moment), that's what brings customers back. It's the experience. Starbucks for example has gone beyond coffee and delivers the Starbucks experience.

The key is to underpromise and overdeliver. I manage a book of work and have clients who make requests for new features,  new data and bug fixes. One colleague who was previously managing the book of work is of the "create dev ticket -> prioritize -> develop" mentality. Sounds fair; sounds like the norm. However, he had created a ticket just for the sole purpose of removing a departed colleague's e-mail address from a configuration file. And then it had to be prioritized and assigned to someone else on the team. I was in disbelief! Removing an email address from a config file takes 30 seconds. Creating a ticket was a waste of time; and then assigning the ticket was a waste of time. He could have just edited the file and been done with it.

Looking for ways to put in the extra mile makes the difference between an average business and a superior business. I've made it my mission in business and in life to see where I can make a difference; where I can go that extra mile and make a client happy. As a manager I would do that extra 'mundane' work so that I can avoid giving it to a developer who wants to do some thing niftier. I have no problem with that. Management is about keeping people happy and satisfied so they continue to do a good job, after all.

Parkinson's Law

I found this on Wikipedia when I was searching for the phrase: If you want something done, give it to a busy person.

Parkinson's Law states that "work expands so as to fill the time available for its completion." A more succinct phrasing also commonly used is "work expands to fill the time available." or in computer-ese, "Data expands to fill the space available for storage".

Application of Parkinson's Law

Parkinson's Law is applied in many arenas of human endeavor.

• In Project Management, individual tasks with end dates rarely finish early because the people doing the work expand the work to finish approximately at the end date. Coupled with the Student syndrome, individual tasks are nearly guaranteed to be late.
• Individuals see this arise in their daily activities as well. No matter how many things one has on their plate, they all tend to get done. This leads to the canard, "If you want something done, give it to a busy person" because it appears they are better at "time management." While this may be true, it is just that they are doing more and the work is not expanding indefinitely to fill non-busy time.
• As an individuals income rises, their costs of living and lifestyle increases to meet their income level.

Note the first thing about Project management above: This means we can never finish projects early or even on time!

There is controversy surrounding Wikipedia and how accurate its entries are but it sure sounds convincing. Is it true? It seems that way from personal experience at work. Software features need to be dropped in order to meet deadlines.

A Thing called Transformation

I wrote this letter about transformation and how it's changed my life to a columnist in the NY Times a few months ago. I wanted to reprint an excerpt here.

...
I wanted to share with you my own story of how I transitioned from
working at home to enjoying work in the corporate world. I was in
consulting work briefly so I spent a lot of time working from home
and, at first, I found it liberating, but then later I found that I
missed the camaraderie and sense of community in the workplace. After
only 11 months at this job, I applied for a desk job and entered the
daily commuting fray once again. I immediately hated it! I hated the
cubicle environment for the first few months, often contemplating
leaving and asking for my old job again. But with patience and advice
to wait it out from good friends, I resigned myself to my job and
decided to see where it would all lead.

My whole first year in my job, I resented being a "cog in the
corporate wheel", as you phrased in your column. I had always reveled
in being the start-up guy (having worked at a number of start-ups),
working in a rapidly-changing environment, and getting things done.
The pace at which the big corporations (with all their
red-tape) move did not suit me, I told myself (I work at an investment
bank). Consequently, I used that as an excuse to slow my own
productivity down. If no one else around here cares, why should I? I
just got by, delivering the bare minimum, complaining about other
people and generally engaging in most of the behaviors disenchanted
corporate citizens seem to engage in.

I had labeled myself as the start-up guy and didn't accept myself as
working at a large corporation. Really giving myself to my corporate
job would mean that I would have to give up my idea (or
label) that working for a startup was way cooler than working at a big
corporation. I realized I could be right about my story and not like
my job or give up my story and throw myself into my job. I chose the
latter.

I wanted to share with you that a big part in my new outlook on work
and even life has come about because of my work with Instantaneous
Transformation, taught by Ariel & Shya Kane. Working with them, I had
a shift: a sudden insight that I mattered and what I do counts. I saw
my cog-ness but it was in a different light. I saw that others relied
on my cog performing well to do their own job successfully. If I got
slow, they got slow. I realized I feed work to other people and if I
don't feed them work, they become disenchanted and bored and complain
about other people's lack of involvement. Soon they would lose their
enthusiasm and become dim and might even look for other employment.

All this became apparent to me in a flash. I caught a glimpse of the
universe and I saw my role in it and that the way I performed that
role was totally my own choice: I could perform it at a snail's pace
or I could perform it brilliantly and to the best of my abilities. I
chose the latter and I continually choose the latter. I feel a renewed
sense of purpose at work and it has become an exciting adventure for
me. I feel that I am making a genuine contribution to the team and to
the firm. I've even gone above and beyond my role by starting my own
initiatives within the firm.

...

To learn more about the Kanes and their amazing work, go to:
Transformation Made Easy

A Case for Prototyping

As a BA, prototyping is an essential function. In fact, I feel it’s probably the single most important thing to do when gathering requirements from users, yet how often do we engage in it? Fred Brooks, a Turing award winner [equivalent to a Nobel Prize for computer science], writes in his now famous article about software engineering, “No Silver Bullet”, about the importance of prototyping when creating software. See excerpt below.

Requirements refinement and rapid prototyping.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. Even the simple answer--"Make the new software system work like our old manual information-processing system" --is in fact too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.

A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptional tasks, respond correctly to invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.

Often times, UAT [User Acceptance Testing] is the first time the user gets a chance to look at the system. And this is way too late in the game to change things (although it is often done anyway). In one project I heard about, the lead BA hadn’t seen a working screen until a month before deployment of the software, after an initial 8 month development cycle!

BAs do use prototyping tools such as PowerPoint and Visio to create screenshots for their users. In some cases, groups may be fortunate to have an Information Architect (IA) on their team who is well-versed in using Adobe Photoshop, or InDesign to quickly do mock-ups and wireframes. This is a great thing to do because it gives the end-user the ability to visualize what s/he will be seeing. However, (1) end-users may glance at a screenshot and just nod and say OK without really digesting it and (2) screenshots still fall short in that behavior of the application is not described or experienced.

Prototyping is the next best thing to having a real application on one’s desktop. A simulation of the software or a raw version of the actual to-be-delivered software makes the user experience much richer and elicits more accurate feedback than any static screenshot can. Prototypes with use cases or scripts are a very powerful combination to drive a focused requirements gathering exercise.

A few prototyping tools that simulate behavior are out in the market already. Mockupscreens (from Mockupscreens.com), iRise (iRise.com) and Axure (axure.com) are three tools that seem to be popular. Indeed, I have used Axure to create a working html prototype (6 webpages) of a car website in 45 minutes.

Furthermore, in many projects currently, software cycles are planned so that the front-end, back-end and middle-tiers are developed and arrive at the same time, all to be released to the end-user. My argument is that we go ahead and concentrate on building the front-end first as a prototype, and deploy it to specific end-users and stakeholders with the intention of eliciting feedback. Clicking on buttons and menus will bring up windows and pop-ups with tables of dummy data that can be prepared beforehand by the BA. This will give as close an approximation to what the end-user will see in UAT but much earlier on in the process. BAs can correct requirements and obtain new ones as the end users ‘demo’ the software.

In each iteration of the cycle, working software is always in place and a constant flow of new functionality is added as the software grows. Again as Brooks says:

The system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below… I have seen most dramatic results since I began urging this technique [Incremental Development] on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness…The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system.

The end users will also get excited as the system takes on the look and feel they desire. Constant back and forth between IT and the business occurs and a positive feedback loop emerges. Collaboration becomes the new name of the game. As IT tweaks the prototype to align with what the business wants, the end users see that IT is responsive to their needs immediately and a collaborative spirit ensues.

One hazard with this method is that end users may be too eager for the system once they see it (even if it’s only a prototype) but these expectations can be managed. The focus should be on building a collaboration; a business user who is much more engaged and eager to deal with IT is far more preferable to one who sits back and has to wait until UAT to finally see a working system that may or may not fill their needs.

A great story in the WSJ

This is an example of phenomenal customer service and of going above and beyond for customers!

From the Wall St. Journal, 08/28/2007:

To a United Pilot, The Friendly Skies Are a Point of Pride Capt. Flanagan Goes to Bat For His Harried Passengers; August 28, 2007; Page A1


Capt. Denny Flanagan is a rare bird in today's frustration-filled air-travel world -- a pilot who goes out of his way to make flying fun for passengers.

When pets travel in cargo compartments, the United Airlines veteran snaps pictures of them with his cellphone camera, then shows owners that their animals are on board. In the air, he has flight attendants raffle off 10% discount coupons and unopened bottles of wine. He writes notes to first-class passengers and elite-level frequent fliers on the back of his business cards, addressing them by name and thanking them for their business. If flights are delayed or diverted to other cities because of storms, Capt. Flanagan tries to find a McDonald's where he can order 200 hamburgers, or a snack shop that has apples or bananas he can hand out.


And when unaccompanied children are on his flights, he personally calls parents with reassuring updates. "I picked up the phone and he said, 'This is the captain from your son's flight,' " said Kenneth Klein, whose 12-year-old son was delayed by thunderstorms in Chicago last month on a trip from Los Angeles to see his grandfather in Toronto. "It was unbelievable.
One of the big problems is kids sit on planes and no one tells you what's happening, and this was the exact opposite."

So unusual is the service that Capt. Flanagan has been a subject of discussion on FlyerTalk.com1, an online community for road warriors.

Mark B. Lasser, a Denver advertising-sales executive, came off a Capt.
Flanagan flight and posted a question on FlyerTalk.com about why the pilot had been so friendly. "I don't trust UA at all but can't figure out what the ulterior motive is," he wrote.

Others quickly came to Capt. Flanagan's defense. "I've had this pilot before
-- what a great guy. He does the same thing on every flight," said a FlyerTalk regular.

Mr. Lasser says he just wishes Capt. Flanagan weren't such a rarity among United employees. "Every flight before and most flights since have been so poor in customer service that this guy really came across as representing his own standards more than the company's. He's an outlier within United,"
Mr. Lasser said in an interview.

UAL Corp.'s United, which ranked in the middle of the airline pack in on-time arrivals and mishandled baggage in the first half of this year and next-to-worst in consumer complaints, has supported Capt. Flanagan's efforts. The airline supplies the airplane trading-cards he hands out as passengers board, plus books, wine and discount coupons he has flight attendants give away. He goes through about 700 business cards a month, and the company reimburses him for the food he buys during prolonged delays.

"He's a great ambassador for the company," says Graham Atkinson, United's executive vice president and "Chief Customer Officer," who is leading an effort to boost customer service. He hopes more pilots and airport workers will adopt some of Capt. Flanagan's techniques such as the frequent, detailed updates he gives to customers.


Air travel isn't easy for anybody, given problems ranging from storms to mechanical breakdowns to computer snafus and lost luggage. Airline workers have endured pay cuts and fights with management; travelers have suffered poor service and unreliable flights. Capt. Flanagan tries to deal with the cheerfulness challenge -- at least on the flights he works. "I just treat everyone like it's the first flight they've ever flown," said the 56-year-old Navy veteran who lives on an Ohio farm and cuts the figure of a classic airline captain: trim and gray-haired. "The customer deserves a good travel experience," he said.

Last Tuesday morning, Capt. Flanagan was at gate C19 at Chicago's O'Hare International Airport an hour before the scheduled departure of Flight 831 to San Francisco and made his first announcement about the delay before the gate agent had shown up. The time posted for departure was 8:20, but that was optimistic, Capt. Flanagan told passengers, because the Boeing 767 they would fly wouldn't land from São Paulo, Brazil, until 7:02 and then had to be emptied, cleaned, inspected and towed from the international terminal.

He tried to lighten the mood, using a joke he tells before every flight. "I almost forgot to tell you, this is my first flight," Capt. Flanagan said.
Wary eyes looked up from newspapers and BlackBerrys through a long pause, before he added, "today."

Capt. Flanagan mingled in the lounge answering questions and using his cellphone to call United operations officials to ask about connections to Asia and to cities on the West Coast.

Ajoke Odumosu, a track star at the University of South Alabama who was on her way to Osaka, Japan, for a world-championship competition, realized that when she began her trip with US Airways Group Inc., her luggage had been checked only as far as San Francisco. With the delay, there wouldn't be time to retrieve it and recheck it for Japan.

Capt. Flanagan called Chicago and learned that the luggage was already in metal containers ready for loading on the 767, and couldn't be retagged. He called San Francisco and found a manager who agreed to pull Ms. Odumosu's bags aside and retag them for Osaka. In all, he spent 15 minutes on the problem.

"I was glad he went out of his way, which he didn't have to do," Ms. Odumosu said.

Once the plane was ready for boarding, Capt. Flanagan passed out cards with information about the Boeing 767. On every flight, he signs two of the cards on the back and, if there is wine left over from first class, he announces that passengers with his signature have won bottles of wine.

When the movie ended, flight attendants passed out napkins and passengers were invited to write notes about experiences on United -- good or bad.
Fifteen were selected to receive a coupon for a 10% discount on a future United flight, and Capt. Flanagan posts the passengers' notes in crew rooms or sends them on to airport managers when they raise specific issues.

Randall Levelle of Morgantown, W.Va., and his family were flying to San Francisco because his father-in-law had just died. Capt. Flanagan invited Mr. Levelle's three children into the cockpit during boarding.

"If other folks in the airline industry had the same attitude, it would go a long way to mitigating some of the negative stuff that has come about in the last four or five years," Mr. Levelle said.

Customer Service!

This blog is about Business Best Practices and specifically about Business Analysis which is what I do for a living, but I expect to cover all kinds of topics that come up.

Let's get down to it, shall we?

Here's a draft of an article i want to write for a newsletter I'm putting together.

Customer Service

Most jobs can be thought of as customer-service oriented. We have deadlines and projects we need to meet and complete but many of us forget that these things are constructed by people.

And then we're given another task on top of what we have, and we holler, we complain (internally much of the time). we'll never get through it, we exclaim.

I think Tom Peters may have talked about this when he speaks of "A Brand of You." Treat yourself like your own corporation. Have excellent customer service. Treat your fellow co-workers as your clients.

"What's the best way to get something done? Give it to the busy person." If you're busy, chances are you're doing something right; You know how to get things done which bodes well for your career, wherever you go. But consider Customer Service: Many of us don't interact with the end-customer or client in our day-to-day jobs but it is possible to re-frame our jobs in a new way: We can consider ourselves a one-person corporation and consider everyone we interact with on the job a client of ours. Everyone knows that customer service and keeping customers happy is one of the primary aims of a company so with that picture in mind, how would you behave differently?

Picture this: You are juggling multiple tasks in order to get projects done. However, you're roadblocked on a few items because someone you've reached out to hasn't gotten back to you. One day goes by, two days, ... one week and so on.

Has this happened to you? We tend to think that when people don't respond to us, that no one but us cares. After awhile, we become disenchanted and slow and complain about beauracracy and large corporations. But pause for a second and take a look at how you operate. Are there tasks, phone calls, e-mail from people who are waiting on you to get back to them? I've found it uncanny how when I clear up my own queue of tasks in which I need to get back to someone (whether it's professional or personal) that something (or someone) I've been waiting on clears up all on its own and I can proceed with my 'real work'.

Also from a customer service point of view, just think that the time you take to help someone with their task will free them up to continue doing their job and for you to move on with yours. You've provided good customer service. This has the added benefit of good-will and enhancing relationships. It might mean taking a breath and biting your tongue and re-focusing; but putting your attention on the present moment and whatever the 'interruption' is can be a very positive thing. It also contributes to an improved perception of you by others. People will perceive you as crisp, on top of things, and attentive, all important and desirable characteristics for any employee. When you go out of your way for someone, it leaves a lasting impression.

This can be extended to beyond returning voicemail and e-mail. How about those tasks you've been putting off for the longest time? Getting to those "non-preferred" tasks will clear up the air, give you a sense of accomplishment and amazingly (in my own experience) open up other doors as soon as you're done with that other task. I call them 'just-in-time opportunities'.

We all know that relationships are one of the primary keys to having a successful work life and for getting things done. People you have good relationships with will continue to help you out and help you move forward in your career.



Organizational and Time Management