Taking Care of Business (Analysis)

The Start-Up of You

2011-07-14T22:57:00.000-04:00

The title is a reference to Thomas Friedman's Op-Ed column in the NYTimes, dated 12-July-2011. Click here for the article: http://www.nytimes.com/2011/07/13/opinion/13friedman.html?_r=1&scp=2&sq=thomas%20friedman&st=cse

It caught my eye because it sounded similar to "The Brand of You" by Management Consulting guru, Tom Peters.

In any case Friedman is dead-on. So dead-on that I came out of semi-retirement to even write this post! :)

I won't rehash what he writes but I will raise examples in my own workplace that illustrates what he states.

E.g., We've been having cuts at the investment bank where I work, and it's just one in a parade of many. People have to constantly look for new jobs or are worried that they'll lose their existing one. Constant re-invention is a must. Workers must always look for ways to add value (which is one of the things I stated in my earlier posts). You can't be idle in this day & age. Look around for what else needs to be done. Kaizen! Continuous Improvement! People who are bored at work simply aren't looking. If you claim to be bored, look at it is a tremendous opportunity to use your imagination to poke into something/get involved and make suggestions.

Another eg. I've seen is what happens after the layoff. In my own group, we were at a height of 100+ people at one point. Now we're down to under 50. People got let go & others left on their own. But the company never replenished. We still have to maintain our ongoing operations however. So what does that mean? Many people are filling multiple roles and are busier than ever. We've gotten pretty damn lean and efficient. And furthermore, we're not just going to hire anyone. We did have a few openings for contractors. But it took several months to fill them. Why? Why when there's a glut of IT people out there did it take us so long? Because as Tom Friedman put it, "we are increasingly picky". We want "people who not only have the critical thinking skills to do the value-adding jobs that technology can’t, but also people who can invent, adapt and reinvent their jobs every day, in a market that changes faster than ever."

I also look at how I can make the job more efficient. I think in terms of the franchise model. The key to franchise success is how to replicate your business easily and cheaply. McDonalds hires burger flippers. These burger flippers don't stick around all that long, I'd gather. It's an easy skill to train them in, and if they leave, you train the next one. And so on. They have it down to a science. Well, even in IT, a similar thing can happen. I am working with a system that has traditionally caused a lot of noise. It takes someone of high intelligence to figure out what's going on. Since I've come into the group, I've whittled the noise down slowly but surely. I've gotten rid of the false positives. Now the system is beginning to hum. Any errors that actually do pop up are being documented in a HOW-TO guide. When I am done, suddenly we don't need that person of high intelligence anymore. That person can be re-assigned to work on more interesting tasks. And in that person's place? You got it: a burger flipper. Someone of mid-level intelligence who can follow instructions and handle basic tasks and attend to those errors. Not the greatest job, but hey, it's a foot in the door and people can move on once they get bored. Even for this job, though, I wouldn't just hire anyone. I'd want someone who could master the task easily and then say "What else? What else can I do?"

Pure PMs vs. BAs

2011-03-26T08:00:00.000-04:00

I've been noticing lately that pure Project Managers on Wall Street are losing popularity. Of course I have only a limited perspective but the sentiment I'm getting is that pure PMs aren't adding as much value. In fact I see a trend towards hiring more BAs with PM experience, or Senior Dev Leads/Project Managers. So some specialty role + PM experience is a more popular choice with employers.

A pure PM might fit into a PMO role better, but an actual project manager doing projects is better off diving into the details.

Collaborating & Engagement with Colleagues

2011-01-12T17:57:00.000-05:00

I am on a new project with new colleagues. I had been working with the same personalities for so long now that I forgot what it was like to go through the Forming/Storming/Norming phases again!

It's interesting to see how some people prefer to work alone even when the work requires collaboration. I actually think this is an easy trap to fall into. In this era of the knowledge worker, each worker has such specialized skills and knowledge of his/her area that it requires serious effort for someone else to intervene and pick up a new task or role. It is just easier to wait for the person who specializes in that area to pick up the task. This can result in long wait times for things to get done, but that's a topic for another post.

A side effect of this type of specialization however is that people start to work in their own silos. Because one person can do so much in just their one area, a type of rigidity sets in and people only do what they know. If something is outside their bailiwick, they will assume someone else will pick it up; or they'll punt the task over to someone else and wash their hands of it and rush back to their own specialty business. In fact, that other person may be new and has no clue and is waiting for direction from you!

It's becoming harder to recognize that picking up the phone and talking to your colleague might be a good idea. A few face to face meetings and phone calls are the equivalent of 1000 emails (or IM chats) just as a picture is worth a thousand words. I moved the project many fold in 1 day than it had moved in several months.

There is nothing like the feeling of several of your colleagues hunched over a screen trying to work out a problem together. Research shows group problem solving is way more productive and efficient than solo solving. In fact, in a project management course I took a few months back I was witness to this exact phenomenon. We were told to do an exercise by ourselves. After that, we had to do the exercise as a group. This provided for a lot of debate because each person had their own views on what the correct answer was. We had to come up with a consensus and convince each other. Eventually we arrived at a solution. Then we graded our own individual solutions and then the group solution. What do you think the result was? The group solution score was higher than any of the individual solutions! I was astounded.

I can see myself get lethargic at times as well and just want to stay at my desk and manage from there. I have gotten facile however at recognizing when this happens and am able to override it and keep myself moving. I will make that extra phone call to push a dev ticket ahead or will sit with my colleague at his cubicle for an hour discussing an issue and how to address it. These are the little things that when added up move projects and eventually implement a company's strategy.

PMP !

2010-12-30T11:42:00.000-05:00

It's official. I have done it. I am now a PMI-certified Project Management Professional (PMP)!

I took the exam yesterday (29-Dec) and spent a little over 3 hours on it. When I hit the submit button to finish the exam, I was fairly confident that I would pass. In fact, during my entire preparation I had full confidence that passing this exam was inevitable.

The reason for my confidence is that I had fully project-planned my entire PMP experience! I made the goal of attaining the PMP back about May 2010. I then realized my company was offering a prep course for the PMP exam in November. I signed up for the course and targeted December as to when I would take the exam. So my milestones were set!

I signed up to become a member of PMI & my local chapter in mid-June. I then spent Saturdays going into the office over the summer to count up my hours. To aid in this, I scoured the web for a spreadsheet that would enable me to easily count my hours. I found one and several Saturdays in June, July & August were spent tallying these hours going back 3-4 years.

The next step was to get these hours into the PMI website. I'll admit there was some slight procrastination here :) Actually, I already had a lot of slack for this task. The hard part was counting the hours. All that was left was data entry. So one Friday night, I stayed late at work and entered all the hours.

The next step came in November when I took the PMP course. I missed a lot of it because of work issues that came up, but the materials in the class were invaluable. It was taught by ESI and I got all their study aids as well as the 9-disc CD set for each knowledge area. I then decided to set a date for the exam in late December and made that my target. For over a month, I studied: Listened to the CDs, read the PMBOK, did practice questions, downloaded PMP apps for the iphone that I could play with on the subway; After this initial stage, I deep-dived (dove?) into each knowledge area. I bought the Head-First PMP book and did the entire book. I then re-took the practice questions from Stage 1, elevating all my previous scores to about 90% and higher. I was already sure that I would pass the exam at this stage. I then took a full comprehensive test exam that ESI provided me with and then the online Head-First PMP exam. On both I scored 85 % and higher.

I then just practiced writing down a few formulas and making sure I knew them cold. And that was it!

It's really amazing how planning this whole endeavor worked so well. I executed flawlessly and mission accomplished!

So tips for passing the PMP: I don't have much to add that would improve upon what many others out there already advocate. Just that you should know your own style of studying. I am an accomplished test taker and so I already knew what would be the most effective for me. Do the same for yourself and you should be fine. A little discipline goes a long way!

Cross-Managing

2010-12-03T00:46:00.002-05:00

One of the most valuable things I've heard on my project management journey is "If you want to be a project manager, you have to first learn to be managed". I was puzzled by this but it was so zen-sounding, I just knew there was some truth in it. That was several years ago and since then I've seen the truth of that statement everywhere. Many people want so badly to be "managers" and feel that by getting their PMPs & learning to delegate, they will have made it in the project management profession. They don't want to put in the time to learn the tasks they need to do their current job really well. They do the tasks to get them over with so they can get onto the next "bigger" thing. In other words, they become close to "un-manageable" in the job they are already in. Why would a senior person trust such a person with an important project to do if they are unable to perform their current job really well?

That's the way to grow in this business of business: Perform excellent work *now* in whichever role or function you're in. Gradually you begin to build yourself up and show yourself capable. Then people everywhere come to see you as reliable and you will increasingly get more work (which is a good thing!) Before you know it, you will become a manager!

However, it doesn't stop there. The entire business of management is not only top down, but also bottom-up (as I've blogged about here: Managing Up). Now, I have yet another addition: Managing Across! What does this mean? It means managing people on initiatives/requests that you have no direct relationship with. So for e.g., since I am in IT, I have no direct relationship with someone in Expense Management or Credit. However they may ask me for something or I might need something from them. There is no on-going project that we're all involved in. Usually it's something like a one-off request. And yes, this can easily be seen as a distraction from current project work. And people may not respond with alacrity. Or they may not respond at all! In fact in some circumstances, you may need to escalate to get your request fulfilled. So in this case, there's nothing really in the PMBOK guide that addresses such circumstances (or actually there may be; I just haven't looked closely enough). However, some of the techniques that are used for managing people in general can be valuable here as well.

Here are a few:

Ask for a favor
Make the request as simple as possible
Make a phone-call OR send an email and then follow up with a phone call: a personal touch is much more effective than an email to someone you don't know
Thank them!
When someone requests something of you in a similar fashion, respond with alacrity and be helpful

Managing Across is yet another opportunity to learn to be managed. We're managed by our bosses, but we can also be managed by colleagues in other parts of the organizations to provide them help/information. It's a constant exercise and requires discipline. There is no point at which you will NOT be managed.

In fact, if I can get philosophical, Life is the greatest manager of them all. Life constantly introduces new stresses and pressures; it changes directions on all of us & sometimes does so whimsically. We all are managed by life in one way or another. So how do you deal with it?

The answer: Being managed at work is a microcosm of life in general and serves as excellent practice! So if you find yourself getting frustrated by requests from others or "distracted" from your project, treat that as an opportunity to be managed. How you respond in such circumstances will be an indicator of how you respond to your life in general.

Too Much Code!

2010-11-24T07:20:00.000-05:00

We are releasing some new software soon and I discovered that the developer put in some extra functionality. This functionality was not requested; He just thought that it would be valuable in case there was ever an issue and we needed to trace things back.

He had mentioned it to me some time ago but I didn't understand the full gist of it and I let it go. However, just the other day we were testing our software and a bug related to this feature came up. So he's putting in a fix for this. The bug was the result of doing some a-typical behavior but nonetheless it's something that should be resolved once detected.

However my concern is with why is that feature there in the first place? It was never requested. Developers need to understand that adding new features comes at a price. I not only serve as PM, but also BA & QA on this project. I am also the PM on multiple other projects and my time is limited. Adding any new feature => (means) adding more code => creating additional pathways => testing more code. This can grow exponentially. Simply put, the price you pay is additional testing time but also increased probability of bugs.

Users who request features with abandon and software teams who accomodate them get into lots of problems. Feature requests need to really be evaluated for the payoff they'll deliver. The thing with software is that it is invisible; you can't touch it or taste it or see it. So it's easy to overlook the amount of time, effort & money that goes into producing it. This message needs to be constantly sent to users in the form of pushing back or pricing each feature. Say No if you don't believe the feature will provide enough value vs. what will go into producing it. Or give a price tag: if they want something the user will have to pay for it somehow: either monetarily (cash, budget xfer, etc) or time-wise (this will delay the next feature x amount of days/months, etc)

You constantly need to remind users of the cost of producing quality software (and that includes QA time). It's easy to forget. Again, I need to point to the guys at 37signals.com; They turn down LOTS of feature requests in their quest to keep their software bug free and clutter free.

Project Management Tip #1

2010-11-12T23:56:00.000-05:00

I was going to write a top 10 list but the first one alone is enough for a post! So here is Tip #1:

Email Communication
When I see email sent from colleagues to several people in the To line and the cc line, I am still amazed to see that people don't address things to specific people.
An e.g. of a bad communication:
"Yes, I agree. IT needs to check whether we have connectivity via Radianz BT to the exchange. Once we know that, Operations can go ahead and request the appropriate credentials to get us going"

Seems like a normal piece of communication. But it's not very effective. Why?
IT & Operations are huge! If the above email was sent to one person, that person know s/he knows to do something, but if you have a number of people on the list, then (and this is the most pervasive thinking around), everyone assumes someone else is doing it! It baffles me to this day why people who send such email also sit around and complain that nothing gets done...

Much more effective would be:
"Yes, I agree. Steve, can you check whether we have connectivity via Radianz BT to the exchange. Once you confirm that, let Rick in Operations know so he can request the appropriate credentials to get us going."

PUT ACTUAL NAMES against tasks! This actually shows that the delegator knows his/her co-workers and their responsibilities which is nice (don't you feel good if a manager knows that you're responsible or good at something?) I even use this tactic if I'm not sure who the right person is. I may just take an educated guess. One thing I know for certain: If I address it to the wrong person, that person will reply back *right-away* and say "I don't do that. Jason handles that" and now I know that Jason should be handling it!

The Dangers of Bad Project Management

2010-11-01T09:08:00.001-04:00

Bad Project Management gives all Project Managers a bad name!
Done badly, it actually can scar one for life and diminish management's effectiveness in running an organization.

Too many people have the notion that all project management is is: issuing tasks for people to do, and hounding people for status. A lot of people think project managers add no value. And I would have to agree: if this is all they are doing, then they are probably not contributing much at all and detract from the project. This kind of project management gives us all a bad image. However, it just doesn't stop there. The damage becomes pervasive: People who have *never even been managed* on a project learn from their peers and others in the organization the attitude of "Oh no, we gotta listen to this guy" and watch as their colleagues roll their eyes at the PM who doesn't know what s/he is talking about.

PMs are caught in the middle between senior management and the people doing the work. From a senior management point of view, if I plan a strategy and want to execute, I look to my PMs to implement that strategy. They are my levers to push and pull on to get the organization to move in a certain direction. So as a senior manager, I need to have trust in my PMs. If I have a negative view of Project Managers, I'll never place much faith in them and empower them to get the job done. I might second-guess, or micro-manage them; basically doing their job for them. That would put me at risk of losing my own job.

I'm sure there are senior managers who have these attitudes but those who are effective senior managers believe in the virtues of effective project management and have seen that it truly is the way to get things done.

My concern is more with the people doing the work. We should be more worried about the effect of project management on the line workers and those in the functional areas. If they're disillusioned by project management and its practices, they won't execute and the whole practice becomes a failure. Many of them have been burned by the application of bad principles, or principles inexpertly or inappropriately applied. (e.g., long, wasteful meetings with too many people or the opposite: badly run scrum meetings) or bad PMs (who stay above the fray and don't get involved and miss key details, report wrong facts, etc). This has a cascade effect as I mentioned above: they don't feel utilized or listened to; they feel ineffectual or that the project isn't going anywhere or headed in the wrong direction or it may simply stall because decisions aren't being made => other colleagues become infected. These personnel may start to look for work elsewhere. The problem with this is they carry the same negative views of project managers with them where ever they go & history can easily repeat itself.

So what's the remedy? Simple! (but more difficult in practice) Hire good PMs; PMs who aren't afraid to get into the guts of the project; to sit down with a BA and have them make that call to the customer to clarify a requirement (I did this just the other day because the BA sounded unsure of what the customer was asking for) or to sit with a developer and get into the details of why something is not working. You don't have to have a particular skillset to do this. You don't have to solve the problem. But just listening alone shows others that you are deeply involved and care what's going on: that you're all one team. And this is the most important thing in project management: Operating as a team.

Project Managers are leaders by definition. Thus they need to also model the behaviors that go into successful execution of tasks. If a BA is uncertain of something, call up the customer. If a developer doesn't know how to proceed, suggest things to google, etc.

Don't bring me problems; bring me solutions!

2010-10-27T00:30:00.003-04:00

or "Don't come to me with a problem if you don't have a solution"

These sayings are some things I've heard along the course of my career.

Now, when I first heard it, I thought it was dumb. I mean why the heck else would I approach my boss? If I didn't have a clue how to fix a problem, then why *shouldn't* I go to my boss?

But just as in observing a jewel & its many facets, there are many ways to interpret the above remarks...

A few experiences have shifted my attitude from the one I previously held.

1. I encountered an issue at work and realized it needed to be addressed with a higher priority than some projects that I was managing currently. I called my manager and told him about this new problem. He seemed to be pretty busy but listened to me and then came right to the point: "What do you need to do?" My first reaction was to feel put on the spot. I thought he'd want to mull it over, hash it out, conduct an exercise in re-prioritization, etc. But instead I responded with "I need a developer and it will take 2 weeks ". He said, "OK, it's important. Do it". Problem solved...

If I were to have not thought of a solution and simply told him the problem and stopped there, I wouldn't have added any true value. I just would have laid the problem at his doorstep and waited for instructions. That's not what I get paid to do. In that moment that I felt put on the spot, I was able to move past it & instead respond with my proposed solution and so he was able to make a decision and give the go-ahead. This is what being pro-active is all about and in that moment, I realized the truth of those sayings above.

2. I had a discussion with a medical doctor about this very same topic and she expressed to me the parallels of this in her own work. She supervises residents who would call her up with the patient's condition and explain things to her. Then silence... The residents wait for her to tell them what they should do. She can of course easily do that. She knows what needs to be done. But residency is training for medical doctors. So she simply turns the tables and asks them what they want to do. "They can suggest the craziest things; it's OK. We don't have to do it, but they need to generate ideas" is what she said. She can identify the good doctors from the not-so-good ones from interactions like these.

I'm not saying that you can't go to your manager with problems. Your manager is supposed to guide you and if you have no clue about how to go about something, then by all means ask your manager. The saying is just a reminder that we always have more power than we think in creating solutions to the problems we encounter.

The Apprentice, Donald Trump & Project Management

2010-10-17T22:53:00.002-04:00

The last time I watched the Apprentice was several years ago (probably more than that even: Omarosa anyone?!). I only had a faint idea of what a project manager did. I never gave it much thought. After all it was just entertainment.

However, I have recently caught a few episodes this season (Season #10) and it hit me that this is exactly what I do for a living! (I only embraced the formal role of PM a little over 2 years ago).

So I've been paying more attention this time around in the hopes of seeing if I could glean something valuable to take back to work. Unfortunately, I haven't learned much, except in the category of what-NOT-to-do!

The premise of the show is such that it pits people against each other from the get-go. Instead of focusing on a task and pulling together as a team, people are simultaneously trying to win the task but also plotting how to cast others in the worst possible light. If that happened in the military, on a sports team or some other organization that was actually trying to achieve something, those kinds of people would be kicked out. Except on "The Apprentice", they're kept around for entertainment.

One idea that I've picked up the last few years is the idea of surrender vs. succumb. I don't mean the literal dictionary meanings but actually from a different perspective. Let me re-define them:

First, succumb: To succumb to something is to give in and accept defeat, but you will make the other person wrong for it. So it wasn't your idea to watch "When Harry Met Sally"; it was your partner's. You actually wanted to watch "Batman", but fine... you'll watch it but you won't have a good time. You'll also ensure your partner doesn't have a good time by punishing him/her so you both don't have a good time.

Now surrender: To surrender to something is to give in as well *but then to treat it as if it was your idea in the first place* How novel! So it wasn't your idea to watch "When Harry Met Sally", but you know what? Why the hell not? It sounds like a blast. I'll go microwave the popcorn. You get the blankets! This creates a win-win situation. You don't punish anyone. In fact you both have a great time.

Believe it or not, this is actually possible! Lots of people go through life not even knowing that this alternative exists. But it does. And the funny thing is: you even forget you wanted to watch Batman in the first place. Life just moves on and you along with it...

So back to the Apprentice. If the teammates could actually allow themselves to be guided by the Project Manager and surrender to his/her decisions, they might actually win consistently and *never* even go into the boardroom! Now that would be a sight... I'm not saying that the Project Manager should be allowed to do whatever s/he pleases; after all, multiple perspectives and collaboration is necessary to decide how to tackle the challenges they are presented with. However, after a decision is made, the teammates squabbling and acting out (succumbing and dragging their feet) doesn't help achieve the objective. In fact it slows them all down, creates a hostile/negative working environment, purges creative energies from the team and makes them vulnerable to losing.

Meeting hatred!

2010-10-17T22:32:00.000-04:00

There's a short blog posting on the NYTimes CityRoom blog about meetings.

Meetings Post

The author absolutely *hates* meetings.
Here, take a look at this humorous poster on meetings.

Also, someone had posted this link about seeing how much meetings actually cost in real dollars (or euros, or other currencies): Meeting Timer; It's pretty cool. Just enter a few values and go! Watch the cost of your meeting add up. pretty scary!

I personally am agnostic about meetings. I've been to meetings which have been a waste of time of course. But I've been to other meetings where we've had to hash out real technical decisions and decide which way to proceed. Everyone's input was needed. A meeting is really the only way to arrive at those decisions.

Agendas are the key to having a good meeting. Know what the meeting is for: know its purpose going in. One meeting I held was because a senior member of the team didn't feel comfortable about a technical choice in the architecture that was made. The software was already tested and running fine and was a few days away from production release but this guy just didn't feel comfortable. So I held a meeting with him and a few other senior people. I quickly took everyone through the architecture, got everyone on the same page and then voiced his concern so we could all debate it. I actually thought that was a good meeting because everyone contributed and came away with an idea of what the architecture consisted of. This senior manager felt more comfortable as well. That was my primary objective actually: his acquiescence to what was going to be deployed. I didn't plan on having any action items come out of it nor did I want to address anything in the architecture that late in the game.

Project meetings where you don't come away with action items are basically a waste of time. When I am the Project Manager running meetings for my projects, I will also take on this responsibility of documenting the items. When I first started out as a PM, I didn't do this b/c I thought someone else would do it (big mistake!) just because 'someone else always did' (and it never used to be me!)

So then I started doing it. But then I realized there was a *huge* benefit for me to do this. It entitles me to become a 'revisionist' (as in revising history!). This sounds a bit dubious but it actually is quite a very useful practice. Let me explain where it come in most handy. In some meetings, there might often be those one or two stakeholders who don't have anything to do with the project itself but throw out 10 concerns: "You're going to want to check this, and then check that, but that might be ok, as long as you check this..." It's usually the case that these people are on the periphery of the project and will actually contribute no manpower whatsoever to the completion of it. They just want to be heard. (Pigs & chickens)

As PM, I believe I have license to do what it takes to get the project done. So on my action list after the meeting, I might conveniently leave out some of the suggested items that were brought up. This all depends on the exact concerns voiced or the level of influence of the stakeholders, etc. There have not been many instances where someone has emailed me back saying I missed something. And if they do, my response is to say "I'm sorry. I've added it now". Because if they do notice it's missing and actually write me about it, I'll take that as my cue that it actually is important. Life gives you the lessons when you need it the most...

The bright side of project practices

2010-10-16T13:12:00.001-04:00

A good article on Projects @ Work about looking at the positives on projects rather than only concentrating on the negatives: On the Bright Side

The idea is to do MORE of the things that went well. Unfortunately, since the tendency is to concentrate on the bad and fix it, we forget the positives and to do more of those. Human beings' tendency to forget what went well and magnify what went wrong is epic. There are a # of studies in customer service that have shown that when a person has a positive experience at a business, s/he will tell 4 friends/acquaintances about it. However, if s/he had a negative experience, s/he will tell 9 friends/acquaintances about it! No wonder we quickly forget what went great and go for the bad...

In this vein, at my own workplace I am suggesting that PMs at the end of each project reflect and think about 3 things that went well about the project and that they would do again (so those are positively reinforced) and 1 or 2 not-so good things (so those could be rectified).

This kind of reflection will increase awareness of the positive things so we can bring those best practices forward into future projects.

Harry Potter & Project Management

2010-10-16T10:50:00.000-04:00

This is a great post on the Unclutterer blog:
Post on JK Rowling's organization of Harry Potter

about how JK Rowling organized her thinking about the storylines of her Harry Potter series. I was never a Potter fan until last year. I dismissed the books as just for kids after summarily reading the first one. Luckily I picked it up again and just became entranced with the whole thing. I devoured all the books and movies one after the other. My life was put on hold until I was done... (I'm sure millions of fans around the world have had similar experiences).

In coming to appreciate the books, it dawned on me that Rowling's achievement was monumental. I was witness to a masterpiece: the books are elaborately crafted affairs with things happening in book 2 that don't rear their heads until books 5 or 6. She didn't just write the 1st book, and then after all the money came in, say "Oh that did well... Let me write another". No... she had these plotlines and twists organized from the very beginning! It is just amazing to see this mastery of organization in action!

Communication within your Project Team

2010-10-15T00:14:00.002-04:00

I saw some things today that really threw me a curveball. Let me explain:
I sank my claws into a new project today. It's basically a collection of 'tickets' that got lumped together and got called a project and prioritized. Each ticket goes through a cycle of requirements -> design -> coding -> QA -> UAT -> Release.

I started investigating one ticket in depth and talked to the architect reviewing the design to see if the suggested approach was feasible. After 15 minutes, I knew that what was being asked in the requirements was too big and that the best way to proceed forward was to descope some things. I called over the Business Analyst who wrote the requirements spec (and who luckily sits a few aisles over) to clarify. The architect went over his concerns and the BA understood and we quickly honed in on a much more tractable solution. The whole thing took about an hour. And furthermore, the solution was so simple, that the architect simply coded it himself! Now we can actually go ahead and test it!

However, it wasn't completely as smooth and easy as I described above. There were some valuable insights I gained from facilitating the interaction.

Some of the highlights are:
1. The architect thought the writer of the requirements document was in London because he assumed the person who created the ticket (who is in London) also had written the requirements; this was not the case. The author of the document was in NY but the architect never even looked at the cover page of the document! There would have been a lot of time wasted going back and forth with the person in London trying to get clarification on requirements when the 2 people who needed to talk most were both in the same location! It's really mind-boggling how something so simple can become so convoluted. We easily could have lost 2 or 3 days if the person in London got involved and tried to be the go-between.

2. We all know one of the functions of the BA is to translate business requirements into technical specs; basically being the go-between for business & IT. One doesn't think there needs to be any kind of translation within IT itself. It's easy to assume IT staff can all talk to one another and understand each other. In yet another twist of events, this assumption has also proven not to be true. In this particular case, the architect is very technical, repeats himself, and elaborates on points to an extreme degree. He is also a non-native speaker of English and speaks haltingly. It does take some effort to really listen and draw out the salient points. The BA isn't very technical and wanted things explained at a higher level. I facilitated the conversation between them. Where the BA didn't understand things, I stepped in to explain. In some cases I would cut off the long-winded explanations of the architect and other times I would ask him pointed, leading questions so he would emphasize something important.
It dawned on me that even within IT, it's dangerous to assume we all are on the same page. Miscommunication can easily happen between 2 co-located colleagues. (Note that this is the most ideal form of collaboration: a face-to-face meeting; yet it can still go horribly wrong!)

The larger lesson here is that a Project Manager with great listening skills can make a huge difference by facilitating interactions between the various members of the team and making sure everyone is clear on next steps. Many PMs just want to stay above the action and merely delegate the tasks to the team members and collect status items to report. They can add so much more value by delving into the details of the project alongside their teammates.

Making it in Financial IT

2010-10-14T08:19:00.000-04:00

I subscribe to the Dice newsletter and there was an interesting article recently on Five Skills you need to Succeed in Financial IT. Click here

It's a good article and very accurate. Some of the things they get spot-on are:

"Educate yourself on both financial terminology and IT best practices," "This will allow you to truly understand your internal and external customers and provide a much higher level of service than someone who just has IT experience."
While your job may include creating and managing trading platforms, that's not your real job. Your real job is to serve the clients, whether they're internal or external. You must know to communicate with people who are very different than you, who are under extreme pressure, and probably not very nice

I really like that they point out that the people we deal with are under extreme pressure and probably not very nice. Very true! You need to develop some objectivity and learn to not take things personally. It's about getting the job done. If you're worried about a bruised ego, you'll probably do better somewhere else. I learned this over the course of my career.

How many projects are too many?

2010-10-12T23:46:00.002-04:00

Very interesting question posed in this article here: https://www.examiner.com/project-management-in-miami/how-many-projects-are-too-many-projects

It's actually an excellent question. I've been handed multiple projects simultaneously myself. Can I handle them all? How much is too much? Will I go crazy?

The article takes almost a mathematical approach, where you seemingly plug in values to a formula and out comes your answer: "Yes, that's too many" or "No, you can handle one more". Of course it doesn't do this explicitly, probably because it's actually impossible but the underlying message is that this problem is mathematically tractable and one can start to hone in on an answer.

I have a different viewpoint. Because by definition projects are unique, and you cannot predict the future, then there is no way you can even begin to apply some kind of calculus to the process. I wouldn't even try. I would let the PM make the determination as to what s/he can take on based on current bandwidth. Some of it is yes, calculated, but there's a whole other dimension involved: Intuition and gut instinct. This plays a much larger role than most people believe, I think.

The article in the link concludes with several tips for PMOs and senior management when assigning projects to Project Managers. However, this is only a one-sided communication. What's left out is: There always exists the possibility of the PM to say No: "No, my bandwidth right now is too limited."; "No, I'm still wrapping up this other project"; etc. Perhaps this is what is called for in some cases. Constantly saying yes to more projects without assessing what you're capable of spells doom for the project and the organization right from the get-go. Brutal honesty is required. Senior Managers must be made aware that there are consequences to their actions, whether it's pulling people off projects they think are 95% done and only a minor effort is left to get the project out the door (in my experience, that last 5% requires a LOT of attention to the details to get right; you cannot for a moment take your eye off the ball) or thinking you can at least initiate a new project early-on while juggling other projects (again, the first phase of a project: initiating/planning takes up an inordinate amount of time).

PMs know what goes into making a project successful; usually a lot of hard work, determination, persistence, constant attention to detail, etc. It's a very easy trap for people who are distant from the action (like senior managers) to think of projects as encapsulated pieces of work that they can juggle and shuffle around and that can be started and stopped on almost a whim. However, the reality is that there is a price to pay for context-switching: slowing down, changing tracks and getting back to speed all take time and energy, not to mention the impact of morale when projects people have devoted themselves to take a backseat or don't get completed.

An e.g.: I have a project that I was asked to manage but I have pushed back twice so far because of other priorities that have surfaced recently. I was tempted to start the project just because of my strong tendency to delve into the unknown and solve problems. However, I've had to hold myself back because I realized that once I started, I'd create an avalanche of expectations which I would then not be able to address because of lack of bandwidth. Again, this shows senior managers that their own choices (about priorities) have created this reality. It's important to have that feedback loop where people can see the consequences of their decisions and actions. Only then will people learn.

Managing Up

2010-10-08T23:09:00.000-04:00

The October issue of PM Network which is PMI's Monthly magazine is all about Leadership. I dove into it only today and have read a few articles but I highly recommend it.

You can access it here: Link to magazine

One interesting tidbit that resonated with me was in the Viewpoints column, called "Led Astray: Sometimes project leaders turn out to be their own worst enemies."

The last 2 paragraphs are about PMs failing to lead up: "Executives need managers who can give them the facts on the ground"... "If you are not effectively communicating to executives the detailed consequences of their decisions, then you only set yourself up to suffer."

How true! I've found this to be completely & utterly relevant to my own situation. I am almost done with a significant project. I have finished up the testing and we are planning the deployment for next week. The change requests to the production environment have been scheduled & approved. In the beginning of the week, however, the senior managers had shifted priorities on the next batch of projects and assigned me as the PM to two of them. They wanted me to start looking at these projects since I was wrapping up the one I mentioned above.

However, my gut instinct was "Hold on. We don't want to count our chickens before they've hatched". Even though the current project is in the deployment stage, there are still quite a few things that could go wrong. I let them know this and they agreed but they also said I could at least start a piece of it.

The thing with me is I like a challenge. I'm always raring to go, especially on new, unknown projects: I like to dive in and take the bulls by the horns. However, I also knew that if I started this project in earnest and started contacting stakeholders I would start creating expectations when I still had my previous project to finish up. Turns out that the project even in the final stages took some unexpected turns. My winding down of the project continued to be a full-time job! As soon as I realized my bandwidth was going to be consumed by some late requirements and shifting schedules, I shot off an email to the senior managers:

"It turns out that because of some late changing requirements and the recent schedule changes, that I need to conduct more tests...; I won't be able to devote time to the new project just yet. If I am able to finish up early, I will get onto this new project and will let you know. Until then, I suggest that the management of this initiative lie with so&so. Furthermore, I am scheduled for PM training on these dates..."

Done! I now had the responsibility of the project off my shoulders. I don't like to shirk off work. I don't like to let people down. I seriously weighed sending vs. not sending that email for a few minutes. But I eventually concluded that there was no way I was going to make any headway on this project as long as the previous project required my guidance.

There was no response to my email! No one convinced me that I could or should be able to do the new project. I got no complaints that I was incompetent or that I couldn't manage my time. They simply silently assented to what I told them. And I was free to devote my energies to finishing up the current project. Or at least bought another week :)

I knew that if I didn't push back on this new project or at least raise my concerns, then I would simply inherit the project and the managers would start asking me for status on the project, despite my having no bandwidth to get anything done. The memory of my having multiple projects would fade and only the weekly status of 0% accomplished would remain. It's important to raise concerns when you have them. Most of successful Project Management has to do with communication and this is a prime example. And this is an example of managing up. If you have no bandwidth, it's not a weakness to let your managers know this. Make it their problem, not yours. If you don't say anything, it automatically becomes *your* problem... and as the columnist wrote: "you have only set yourself up to suffer".

Article on Personality Types: Business Analyst vs. Project Managers

2010-10-03T08:57:00.000-04:00

Here's an article I had the pleasure of writing for the Projects@Work newsletter.
Link to Article: "Is Personality a Requirement, Too?"

You will need an account to sign in and read the entire article but it's a good site with lots of good information and I recommend it.

The origins of the article come from this earlier post on the same topic.

Importance of Feedback

2010-09-30T23:51:00.003-04:00

Coaching; Feedback; Important Stuff!

I've been thinking about this because of my latest passion: taking spinning classes!

Our minds tell us we have reached our breaking point and we possibly can't do anymore. But listening to the coach, he tells you to turn it up and if you listen and do it, you achieve way more than you possibly think you could have. All through the class, he kept telling us to turn the knob to the right, and I kept doing it; and then when the song ended and he told us to sit it down and ease up, I realized how far to the right I had twisted the knob and how difficult it was to keep spinning AND I KNEW that I myself would never have pushed myself to spin that hard!

There's a famous quote by Einstein:
"You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew."

Listening to your mind, your own closed system of what's possible and what's not will NOT bring out your best. You need to be able to take direction from the outside. Coaching can really bring out your best. All top performers in any discipline require coaches; Coaches can see your true potential before even you can. Skilled coaches can bring out your true potential.
I would never have gotten to that difficult level of spinning on my own or even thought I was capable if the coach didn't push me to get there. It was simply out of my reality!

So whatever you're interested in: go seek a coach, mentor, buddy, whoever; Life Coaches, Executive Coaches, Personal Trainers, etc; go for it!

Status Reports...for Yourself!

2010-09-19T23:24:00.000-04:00

This is about Updating your weekly status reports even if it's for YOURSELF!

First of all, if you're a PM and you're not having regular reporting meetings (weekly, bi-weekly, monthly, whatever it is) with your boss, take the driver's seat and schedule them. S/he will be grateful for it.

If you have the attitude of seeing what you can get away with and not reporting status on your projects (like I did in the past), because you think there's not much to report, or you think you can coast for a while, then time to shift into overdrive! Making this into a routine practice is important for many reasons including:

Your boss doesn't have to chase you and wonder how the project is faring
You get the help you need: Even if you have it under control, your boss may have an alternate viewpoint or helpful tips or stakeholders you need to consult to make sure you have all the bases covered, etc.
Your boss can help your with risk assessment and mitigation

The biggest benefit of a regular reporting practice is not for your boss but actually for yourself!

Preparing the report ahead of time clarifies your thinking and makes you think of what exactly you want to report. You have to put yourself in your boss's shoes. You don't want to put too much detail in the report but you don't want to make it too high-level either. Only by understanding your boss's needs and how s/he thinks will you arrive at the appropriate level of detail.

Furthermore, preparing the report will allow you to see if you made any real progress since the last period. It will give you perspective on what you're actually accomplishing rather than what you tell yourself you think you accomplished. Nothing makes it more real than writing it down. Your thoughts are usually very different from reality! So think of these reports as reality checks.

My own manager was out of the office for the week (I have a weekly status meeting) and so I didn't have to prep for the meeting that week. However, I went through with the exercise anyway and it was very revealing. Acting as though I had a real status meeting, I was able to see what was accomplished, and what was not. There were milestones that were achieved but on a smaller scale so I had to break those down into more fine-grained milestones. I then folded these back into my project plan, estimated durations and came up with new dates. I was also able to assess risks, and contact stakeholders for more information. That to me was amazing. It represented real pro-active project management. And I had no one breathing down my back to do this. PMs need to be real driving forces in getting projects done. This is something I'll talk about in a future post.

Opening the Package

2010-09-18T00:12:00.001-04:00

There's a brief parable I read once that described a beggar sitting on a wooden crate asking everyone who passed by for money. One day someone stopped and asked about the wooden crate he was sitting on. The beggar shrugged and said it was just his seat. The stranger said "So you never looked inside?" And so the beggar opened the crate and found a pile of gold.

That's it. Pretty simple. The lesson is obvious right? But how many times do we operate in our own lives like that beggar?

At work, we had a collection of development tickets that were being passed around from group to group looking for a home. No one wanted to own them and work on them. They looked like a hassle to deal with. Finally, I got them. What did I do? I clicked on each one and read the description. Then I made a few phone calls. 3 out of 5 of the tickets were obsolete and the other 2 were going to be resolved in a re-design of another project that was already in progress! Voila. Problem solved; it took only a 1/2 hour. The tickets were marked as deprecated and closed however these tickets had been passed around for several months!

Lesson: open the package. No one wanted to look inside! But once we did, the weight was lifted and it was painless...

This also happened in my personal life. I had bought a poster in California that was rolled up. I had to get it framed. I thought I knew the dimensions of the poster and that I needed to get it custom framed. I gave the dimensions to a framer and they gave me an insane price. I didn't act. The poster languished for 2 months before I took further action. This time, I actually unwrapped and unrolled the poster. And you know what?? The poster's dimensions were nowhere near the dimensions that I thought they were! They were much smaller and consequently cost much less to frame. Lesson: Open the package!

Project Managers as Contractors is the WRONG way to go!

2010-08-13T21:30:00.001-04:00

Everyone knows that project management in today's organizations is essential to business success. Without projects, you don't accomplish new business objectives. The discipline of project management is your best bet in reaching those objectives.

However, there seems to be an upward trend to hire project managers on a temporary basis to run these projects. I've seen it in my own organization and I've seen it with ex-colleagues who have gone on to take contractor positions in firms for the life of a project.
Indeed, the August issue of PMI's magazine PM Network has an item about this in The Buzz. Click here to read it.

One sentence says "...the temporary nature of projects makes them particularly good candidates for contract work".
This is quite true. It does seem like that...so what's the problem?

The problem is that effective project managers should be in place longer, much longer than just the life of the project. They are the ones that should be there permanently! PMs have more clout, more influence, and talk to more people than anyone else on the project. Their reach extends far and wide. Would you really want to lose all that after a project is finished?? If you find an effective PM, you keep 'em!

The ramp-up time for a new PM to be effective can be very long. For the PM to learn what makes their stakeholders tick, how to influence each and every one of them, to build relationships with them, along with the BAs, with the people doing the work, etc takes a very long time. The hub at the center of the wheel is difficult to replace.

So I've made my point about keeping PMs for the long-term. But what do you give up in this kind of environment where contracting is the new norm?

The solution is: The line positions that executes should be turned into contracting positions. Developers, architects, QA, support staff, for e.g.

If you have a strong PM & BA who are intimately familiar with what needs to be done, they can train new people to do exactly what they need them to do to accomplish the project goals. Especially with newcomers to the organization, it is important to get them off to the right foot and train them in the way you want things done. Then they will be able to deliver. We have a new QA person in Singapore who I will be training in our application. I will spend some late hours with him to get him up to speed but I will show him exactly what he needs to know. I don't mind doing this, because the payoff will be immense.

There is more of an impact on an organization's capability to deliver if you lose a PM vs. any other position. In my own case, I have been delivering in my space for nearly the last 2 years, and I have the confidence of the people around me that I am true to my word. This makes it easier for them to trust me and approve things. A new PM would have to build these relationships from scratch.

Furthermore, in today's agile world, no position is safe. If you're not advancing and continuing to build your skillset and your relationships, you're in danger of losing your job. Indeed, in the very same article, there is a quote, "When I hear people talk about temp versus permanent jobs, I laugh. The idea that any job is permanent has been well-proven not to be true."

So why should a developer who knows how to code a certain financial module (for instance) be so secure? Some people may think they have job security because only they know the module. However, if they're not performing, they should face the consequences, not be given free reign.

Plus, I'm willing to bet that a good developer or architect who comes fresh into a job and is given a mission (I need you to do x, y, and z and figure out how to do this) will see this as a challenge and figure out how to get the job done. Indeed, in my role as a BA on some projects, one of the pleasures I take is in coming fresh to a project and piecing together the puzzle of what needs to be done... This way, I start to own it.

Good, Cheap, Fast

2010-08-08T14:13:00.000-04:00

At my local bike shop: They got the triple constraint down pretty well!

The Invention of Process

2010-08-08T10:13:00.001-04:00

Just finished reading "Rework"( Link to Rework )

As usual, class-A material from people who execute well. They have their act together...truly. I love the fact that their goal isn't to cater to the Fortune 500...they cater to the Fortune 5,000,000! The know where they stand and that's where their power comes from.

There's a chapter towards the back about Policy, and how in many instances, policies are "codified overreactions to situations that are unlikely to happen again." I totally agree!

This brings to mind a quote from a book that I read a long time ago on the making of the atom bomb. Edward Teller, a Nobel Prize winner and father of the hydrogen bomb, was advocating the use of a bomb on an asteroid as an experiment. Someone remarked, "If you've got a problem, Eddie's got a bomb!" Basically there were a lot of idle bomb experts sitting around after the war ended...

Well, the same holds true for process: If you've got a problem, [Insert Name here] down the hall has a process". The proliferation of processes is something you've got to watch out for. Several things can happen:

1. The process is actually too cumbersome, and people circumvent it.

2. It leads to a false sense of security that everyone is doing the right thing and that they're delivering quality software because all the i's are dotted and the t's are crossed.

3. Following the process doesn't mean you're even delivering anything of value. To be zen here, "Like the finger pointing at the moon, the finger is NOT the moon". Likewise, following a process is no guarantee of anything. It just means that some auditing team can catch you if you didn't upload some documents in a timely manner.

Ditto for templates...

A Software release Today

2010-07-24T00:26:00.000-04:00

Our team released some software this evening and it was a completely smooth process. Everything just worked! There were absolutely no hiccups. Everything that we expected to happen happened. Nothing unexpected happened, or if it did, we were prepared for it because we thought it might happen.

It is an indescribably satisfying feeling when things go according to plan! Now I know what Hannibal Smith meant when he said "I love it when a plan comes together".

To give some background, we had been planning this release for 2 weeks. I had an hour by hour runbook all set up. It was edited countless times & reviewed in several meetings. I also emailed everyone under the sun about the release.

The email was a point of contention. I felt that emailing EVERYONE would invite unnecessary questions about the release and possible interference by people who needn't be concerned but just wanted to put in their 2 cents; this was remedied by my mailing instead a select few who really did need to know AND by putting in full assurances about how much we tested this and that there were no issues in testing AND that we anticipate none after go-live AND how we will be in heightened alertness mode at business open. The result: "Thanks for letting me know." Problem solved. Lesson Learned: If you show confidence in your product, then people will believe. You just better deliver.

The beauty of being the PM is that all the work that I did in the planning, I witnessed the execution of at go-live. I didn't have much of a role in the release. I just asked a few questions but basically watched the event unfold. It was like being a movie director at the premiere of the movie.

It really does go to show that planning through a project pays dividends. There is a mentality of 'winging it' where some people pay lip service to planning, and might think through only a few things and leave the rest to chance. This experience has proven to me w/o a doubt that you can really execute according to a plan and be successful, as long as you have sufficient time to think things through.

37 Signals Stuff

2010-07-19T00:53:00.000-04:00

From the guys who created BaseCamp, here is a link to their book "Getting Real" on software development. Completely free on the web!

Getting Real

They also have a new book called Rework which I aim to read soon.

These guys are on the money with their stuff. Very readable, very applicable, very excellent!

For instance,

Get something real up and running quickly

Running software is the best way to build momentum, rally your team, and flush out ideas that don't work. It should be your number one priority from day one.

Click on the link above to read more...

Project Management Top 10 Problems

2010-06-16T22:09:00.000-04:00

This isn't my list. But you can see this one here:

The Top 10 Mistakes

These all ring so true.
For instance, #2 :

Believe that good scheduling software makes one a good project manager

Forget it! Like the post says, many people just get frustrated with Project thinking it will be like Excel and eventually give up.

There is a learning curve to this and it takes time (like with any new skill) to master it.

Project Plans are a personal matter!

2010-06-04T22:50:00.001-04:00

Project Management is a very personal thing. It takes time to develop your own style and individual approach to the discipline. My recommendation is to try different things until you hit on something that works for you. And then share it. Despite all the standardization that the PMI has done with the discipline, you need to find ways to make it your own.
For instance, I hated using MS Project. I always had trouble with it, mostly because I never really dived in to learn it thoroughly.

So I went to an Excel spreadsheet to model project plans (which I stole from a colleague). I created a daily chart and color-coded it. I insert comments for each task and put down the # of hours I spent on each task. Voila! I have a written record of how I spend my time each day. I duplicated this sheet and made it weekly. So now I literally have a roadmap of all my releases for the next few months. I thought I was fine managing from Excel only.
However, I came back to MS Project because I realized I couldn't properly get good end-dates and that Excel won't calculate these and take into account weekends and holidays. In MS Project, I found that you can even adjust working hours! Then, as I got more and more interested, I realized the value of baselining and comparing actuals to the baseline and computing earned value (the holy grail! but still a work in progress).

It is not a simple thing to model real-life tasks in a software tool. But as I got familiar with Fixed Units, Fixed Duration, Fixed Work, & the various constraints & dependencies, this got easier. Now I'm in a position to more realistically model project tasks.

Now I flit back and forth b/w Excel & Project. Each gives me a unique way of managing my projects. I have a roadmap view, I have a log of how I spend my hours, I can see the progress of my project, etc. Someone could easily say that it takes too much time and I only need to use Project for everything. But I like this method. I feel I have more control and oversight of my domain. So you see, Project Management can be a very personal thing.

What's important is that you're able to manage. Managing by objective is key. If I give a due date for a project, it's important for me to constantly see if we're getting closer or we're slipping. That's all that matters. Not how pretty my project plan is or whether I use Excel, Project or a piece of paper.

BA & PM Personalities

2010-06-04T21:56:00.001-04:00

Bear with me on this one...It occurred recently to me (and it jives with personal experience) that:

A PM should be pushy in order to get things moving and done
A BA should be inquisitive and customer-focused

If you have the personalities reversed:

A PM who is not so aggressive and who wants to gain consensus and make things right before commencing on a project, you might wait a loooong time before a project gets done.
A BA who is pushy & aggressive is the most dangerous; they can really throw your project off because the BA may not gather all the details necessary to do a thorough analysis, does not listen to all the nuances and communications a stakeholder emits; s/he may not communicate all the details to the development team because they're off to the next project, etc.

Slideshow...Enjoy!

2010-05-11T21:55:00.003-04:00

Risk in Project Management

2010-05-01T14:39:00.000-04:00

I want to talk about risk in IT projects.
I don't feel we do a good enough job assessing risk and constantly staying on top of it.

Why?
IT Project Managers are under enormous pressure to deliver so looking only at the sunny day scenarios gives them a sense of optimism. Dates are then promised based on this scenario and everything is done to make that date. Risks are ignored, hoping they'll go away. Turning a blind eye is easier and then throwing your hands in the air is the final resort when the realization hits that there's no way you're going to make that date.

The nature of risk is that it's neither good nor bad. It just is. And it always exists. Hence it needs to be managed. Ignoring risk imperils projects, plain & simple. Another aspect of risk and more important, is that it constantly changes. Staffing changes can occur -> Risk occurs. A project can move from the requirements stage to the design change -> Risk occurs. In fact, every single day a new risk can reveal itself. Therefore, it is important to be constantly assessing for risk.

In simple terms, managing risk basically means staying on top of your project. You just can't do all your planning, baselining, draw your Gantt charts and say "GO!". After you put the ball in motion you have to watch where it goes constantly and re-adjust yourself, and your team (Tennis analogy anyone?)

So the first piece is to constantly monitor risk. That part requires vigilance for the duration of the project. You can do this via using checklists, talking to people, going to training, asking questions, etc. The 2nd and most often-neglected piece is to mitigate the risk. Identifying risks is not enough. Sometimes a risk makes itself apparent to you and everyone else and if it actually does occur, people tend to throw their hands in the air and complain and the project fails to move forward until it gets escalated. Someone from high on up chimes in and then the project starts to move again.
This is bad. Your boss or boss's boss shouldn't be managing your project.

The key is to assess the risk earlier and have a mitigating plan in place to deal with the risk. That way, if the risk actually does occur, you can follow the plan. Remember: to fail to plan is to plan to fail.
I find that there's not a lot of mitigation planning going on. Risks are usually left unattended. I've done this personally. I hadn't even realized I was doing this until some recent experiences have burned me.
Mitigation of risks is an extra step after identifying the risk and requires further research and thought. You need to reach out to others for help to see what can be done, who can act as backup, etc. It all seems like extra work beyond the actual work needed to get the project done. Perhaps this is why it is neglected. But it is absolutely crucial to do.

Overworked and juggling too many projects? That is a risk. Some projects need a dedicated Project Manager to see them through. Identify that as a risk and tell your boss or PMO. If they are made aware of it, they can remedy it.

More later...

A quote on leadership

2010-03-09T22:24:00.000-05:00

I love this quote on leadership by Lao Tzu, the founder of Taoism:

A leader is best when people barely know he exists, not so good when people obey and acclaim him, worse when they despise him....But of a good leader who talks little when his work is done, his aim fulfilled, they will say, "We did it ourselves."

Plugging In

2010-03-06T11:20:00.002-05:00

What I mean by 'plugging in' is the ability to deliver needed capabilities as a project evolves over time.
For instance, I was assigned as a QA resource on a project which is what the manager on the project felt he needed. It soon turned out that what was really needed was an env manager to sort out issues currently experienced in UAT by outside users. So I straightened that out. Then I started sending out emails about the resolution of those issues daily. Then we got out of firefighting mode.

We've been able to move forward but now other issues have cropped up: we decreased the scope of our release but the other groups weren't notified so a change in the strategy was needed. I made sure this happened.

So now I'm communicating daily with all stakeholders about the status of the project. Sounds like what a PM does eh?

In addition, as those things get sorted out, I am actually doing some QA on the side and noticing things that are off-kilter. I'm communicating these to the dev team for fixes.

So what I am trying to communicate here is 'plugging in': the ability to fill in gaps as they arise. So I'm doing PM & QA/UAT and Env mgmt. The project takes a life of its own and as usual, we are short on resources. I can scream that I was only assigned to do QA and that I shouldn't be doing anything else, but I choose to engage on all levels and move the project along by seeing what needs to be done and doing it.

What it really takes to make it as a PM or BA in this industry is to be a generalist with a passion for learning. To speak with colleagues on the phone an ocean away whom I'll most likely never meet and to understand their pain from their point of view (netmeeting, webex anyone?) and then to demonstrate that pain to an SME who knows how to fix it. This is how I plug in. The SME may not be able to talk directly to the user because of time-zone issues or an inability to properly communicate, etc so I fill that gap.

It's taking care of the simple things: building the small bridges that most people overlook. I like to say that 'adding value' to something doesn't necessarily have to be a big-bang type of thing. You just see what needs to be done and do it. You see where things are being dropped and pick them up. Not rocket science, but it makes all the difference.

Eventually, people will think of you as a go-to person, someone who doesn't drop the ball, who gets things done. And nothing is better than that if you're worried about job security!

The giving of thanks

2010-02-27T10:59:00.003-05:00

We recently had a change in management in our group and we have a new head boss. He's already been here a few weeks & is based in London. He came to NY recently and I met him as he did his rounds. That same day, this project I was put on in the last 2 weeks got escalated to him because the stakeholders weren't seeing any progress. This is the highest priority project we have right now and is already late. I got put on the project because I have an excellent track record in QA (which is *yet* another hat I've been wearing in the last year! More on that some other time).

Long story short, the same day I met him, he must have come to my cube about 5 or 6 times to get status updates! There was a quirk in the system that wasn't allowing proper comparison of BEFORE and AFTER files, so the users couldn't compare accurately.

In order to debug this thing, I pulled in resources from North Carolina, India (I called the guy at 6 AM and had him on the phone until 12pm which is 11pm his time), Houston and NY all to figure out this quirk. It was intense and I put in a lot of hours. We never figured out why it was failing but we instead devised another test procedure that was acceptable to the stakeholders.

I've also been placed in charge of all status updates to the stakeholders, so I sent out regular communications to them giving the latest status. I made sure these emails were clear, and detailed who was responsible for what. We steadily made progress and have nearly cleared the entire list of issues.

My boss sent me a note of thanks after each one with things like:

"Excellent work"
"Awesome work. Push this one over the line"
"You have taken ownership and this is exactly what I expect of people to do."

Can you believe the impact of one line like that ? It's indescribably awesome! These are emails I will stow away in my personal folder that I can come back to if I want a lift or to show off (I sent one to my Dad!).

Lessons Learned:

Why be stingy about thanks? Some people don't have it in their nature to be effusive but that's not what's even required. A simple note of recognition can go a long way.
Engagement, engagement, engagement! This guy was after me for updates and sending out emails to the stakeholders keeping them informed. He knew that the reason stakeholders escalated to him in the first place is that they were in the dark about the project and they felt nothing was being done. The first thing he stressed to me was to keep them engaged, and that is what I started to do. The cool thing is that he did it by his own example: he engaged me! He's the one that kept coming by, called me and IM'd me. So I became that way! Modeling the behaviors you want to see in others...how novel!
Test the heck out of something. and test it smartly and efficiently. My belief is to test the software so well that you should be aware of any issues before you go into production. And then either resolve those issues or have workarounds. You don't want to go into production and then wind up seeing a problem you've never seen before. Preparation is key. Granted, there are times when something unexpected will happen and we have to deal with it on the fly. But this is rare and my preference is not to deal with the rare. Why spend a dollar on a 10 cent problem?
Ideally, there shouldn't be any need for 'heroes': You know that special go-to person on your team who knows the system inside out and can solve your problems in a pinch. Things should never get that bad. I should have all issues worked out before I go to production and whatever issues there are should be transitioned to the support team so they know how to deal with it. I prefer saying instead that "everyone can be a hero!" and everyone can be if they all perform their roles to the utmost, don't drop things and take an active interest.

Where the heck have I been?

2010-02-27T10:39:00.007-05:00

Well, I've taken quite the break there! Where have I been? I'm still at the same firm, just extremely busy. And plus, I just saw "Julie & Julia" and it brought back to my mind this blog. I've also been soaking in a lot of new experiences. In a way, I feel I've graduated. Joining my 'new' group (in late 2008) after my last BA position was like being hazed. It was like going from the minor leagues to the pros. We have to handle IT for all groups like Front Office (traders), risk, product control, operations, financial accting etc. I became a PM in the Architecture arena and I had to manage database migrations, and upgrades of various software components: work that could only be done on weekends and evenings and in a timely, controlled manner with lots of testing beforehand. It was anything unlike I had done before.

What was different?

As a BA I was responsible for only one part of the project and getting that right. As a PM, I am responsible for everything. Talk about pressure. And especially on projects where the DB better be back up on Sunday night (Monday AM in Asia)
I had to get people to do things; I am not an official manager. No one reported to me. I had to keep pushing. There was no time to sit still and coast after I got one thing done. There was always something else to look at. PMs can never sit still!
I find a satisfaction in being a PM that I don't know if I had being a BA. Not to say that one is better than the other. But there is something to be said for utter and complete accountability and responsibility of a project from start to finish. It all lies with you. You make or break the project.

There are tons more differences and not everything can be listed. But my experience as a BA has helped vastly. I can break down a requirements document and find holes in it very quickly and then have the authority as a PM to get them addressed. And I don't mean to imply that I don't trust my BAs but I've seen some pretty bad requirements specifications and usually accompanied by no test case documents. "Trust but verify" is an adage I like.

Let's look at QA!

2008-09-05T23:01:00.003-04:00

A personal note: I've formally left my BA position and am transitioning to a Project Manager role (PM) in another group at the bank I work in. Not to fear though. As a PM, I will have oversight of all the activities going on, including BA, QA and development.

I've been thinking about quality for the last few weeks and I've realized that we really aren't doing a good job at QA. At least on the first few tries! We release software that is riddled with bugs, that have data integrity issues and crash as soon as the user tries something new.

First of all, where I am, QA is given short-shrift. We don't think of them till the very end. They're out of the loop for the most part and then are brought into Mission Impossible: Make sure this application is ready to go in 3 days!

The thing they say about quality is true: You never have enough time to do it right, but you always have enough time to do it again!

How do we ensure quality? or more realistically, how do we aim for as high quality as we can get? Quality is elusive. Heck, Pirsig wrote a whole book on it (Zen & the Art of Motorcycle Maintenance).

Well, I'm no quality expert but I have learned a few things in the last few months.

You need to have a separation of concerns. The team pushing out the software (BAs, PMs, Devs) should not be responsible for Quality. You need a Congress to push back on the President. The mindset for driving out and releasing software is at odds with ensuring quality. I've signed off on software to be released just so I could get it out there only to find that there was a crash a day later. My goal as a BA is to satisfy the user and to get the software out, not to find fault and hold it up. As long as the former is my motivation, I cannot do an adequate job of QA'ing anything.
We need to have some sort of up-to-date specification to hand off to QA. I've been a cowboy for the last year or so, BA'ing by the seat of my pants, embracing agile, and iterative development. Which really translates to: No writing any specification documents. I would instead create prototypes, mockups, write up notes in Excel and have plenty of phone conversations and netmeetings with my team. This was swell and we produced some good results which were very close to the mark to what I required. However, QA suffered. The way I handled QA was to also do the netmeetings, and do demos and such and then let them play with the software. QA could write up their own test-cases based on what I showed them. Voila! No spec needed. After all development created the software without a spec either. However, and here's the kicker: I realize now that I only show QA what *I* think is important. I demo features that I think should be tested, so when they go away, they concentrate on that. Of course it's the features that I don't show them (because I don't think they're important to demo) that wind up being used by the user and then fail! It's really remarkable (and arrogant of me) to think that I know what QA should do. Again, as a BA or anyone looking to driving software into the marketplace I am severely hampered by this same motivation from ensuring as high a level of quality as the software (& user) deserve. So which translates to: have a spec ready that highlights what the software does and let QA work off that, not what I show them. Guess specification documents are a *good* thing! :)

What led me to posting this about QA was some recent experiences (or failures) with our tools. I did an analysis and here's what I've come up with.

1) Bug because of a hidden feature that wasn't tested.
Occurred because (1) I didn't demo that feature to QA (see point #2 above!), so QA never even knew to look for it or that it existed, (2) test cases from v1 of the tool were not reviewed and used for v2; the test-cases may have had this hidden-feature; in essence, no Regression-testing! and (3) there was no written spec given to QA which would have had this feature detailed.

2) Bug because a common case was not tested.
Occurred because again (1) I didn't demo this to QA or stress it at all as a point to be tested. They saw what I showed them and mimicked it. (2) Test cases from v1 not reviewed and used.

There were a few other things that contributed to the breakdown:

Inadequate training of QA; a junior QA person with not much experience signed off on the project.
QA not brought in early enough to the specification phase of the project
QA spec/test cases should be developed ahead of time and be prepared/reviewed. QA needs to have this as a mandatory deliverable. Even if they are brought in dead-last in a project, their efforts should result in a test-case deliverable that can be re-used for the next go-around.

So in summary, here are some essentials:

Always get QA to hand over a test-case or QA deliverable that can be re-used or handed over in case resources get shifted (QA seems to be get 're-deployed' more than any other group these days)
Use above deliverable as basis for modifications and to use for regression-testing in major releases
BAs need to write a spec specifying what the system does as a deliverable to QA (and to developers, although in my instance, I don't seem to have all that much trouble getting development to deliver what I want since we're both aligned towards the same goals) so they can poke holes and create their deliverable.

QA will either use your spec (or any other documents, literature, conversations, screenshots, etc) or if brought in really late, will use the actual working software itself to create test-cases. This deliverable is vitally important. (Implementation-wise, if QA keeps it in a doc or in a tool like Quality Center, it is irrelevant)

A PM's utility

2008-06-14T15:17:00.004-04:00

Warning: This post is really an experimental one; just playing with some thoughts about the PM function. Not my intention to offend but the question is:

So how useful are PMs (Project Managers just in case you didn't know)?

Frankly I'm not very sure!

Of course it depends on the project. Not every project needs a BA or PM.

Everyone on a team should be thoroughly invested in 'caring' about the product, not just task-mastering so that things get done. PM activities are essential actually. But is a separate PM truly necessary? I think the best approach is to either hire BAs with PM experience or Developmental Leads with PM experience. That way PM tasks are kept to a minimum but also reside with personnel who are invested in the product.

In Six Sigma terms, the most useful ppl to have on a project are those who are adding value to the product.

A BA talks to the business and therefore represents and speaks for the business to the dev team. The BA represents the business so s/he wants to ensure a quality product.

The developers are developing the product and so will put care and precision into crafting something of quality.

In my own (and certainly limited experience) PMs engage in many not-required non-value-add activities. Is the customer willing to pay for communication or chasing down people to get tasks done? These are overhead tasks that are necessary but also don't add value. In six-sigma terms, these are NVA, non-value add activities and should be minimized. Hence, my call to eliminate the PM position in areas where you are able and to place only the least amount of PM activity with other members of the team who also engage in value add activities.

Let's look at wikipedia's definition of the activities a PM engages in:

Analysis & design of objectives and events
Planning the work according to the objectives
Assessing and controlling risk (or Risk Management)
Estimating resources
Allocation of resources
Organizing the work
Acquiring human and material resources
Assigning tasks
Directing activities
Controlling project execution
Tracking and reporting progress (Management information system)
Analyzing the results based on the facts achieved
Defining the products of the project
Forecasting future trends in the project
Quality Management
Issues management
Issue solving
Defect prevention
Identifying, managing & controlling changes
Project closure (and project debrief)
Communicating to stakeholders
Increasing/ decreasing a company's workers ...

In particular contexts, these activities make sense and in others they don't. If you're running an agile or lean software development project then a lot of these can be eliminated entirely and others can be offloaded to other personnel.

The gist of this post is to just get you thinking on the type of projects you're running and not to blindly throw a PM, BA, Dev Lead team together and expect to get the job done. You could be slowing the project down actually. The BA and Dev Team could run with the project a whole lot quicker than with a PM overseeing everything trying to get updates.

In my environment, what seems to truly work is:
1) Hire BAs who are comfortable with and can talk to both the business & development on an everyday basis.
2) Hire BAs with PM knowledge
3) Hire Dev leads with PM knowledge

Lean Sigma Thoughts

2008-04-05T17:54:00.006-04:00

I've recently been going through some training on the Lean Sigma methodology. It's all about Process Improvement and it employs the DMAIC (or DMAEC) steps: Define, Methodology, Analyze, Implement (or Engineer) and finally Control.

It's a very sequential model (not unlike a waterfall software life cycle methodology) with tollgates at each step. It's pretty interesting and I'm learning a lot of academic material. I'm doing my Green-belt training and I am using the textbook material on an actual project that is causing my boss pain. However, as I've been digging into the project, I've discovered that a lot of the steps were carried out 2 years ago on much the same pain points. In fact, there are reams of documentation all the way to the Engineer Phase. The solution was never implemented however. Now there's a big project underway (of which I'm working on a very small chunk) that is looking at the same issues again. So my question is: why? Why will the result be different from last time? Why wasn't the last solution that was brought to the table 2 years ago not carried out?
Heck, we can do a Lean Sigma project on this question alone!

And furthermore as I was digging into the items, I started getting innovative ideas. What if we could do this or that? and implement it with a small group? If it worked, we could spread it to the other groups. And then it hit me. The Lean Sigma process to some extent is devoid of innovation! That flash of inspiration; that 'hmm, what if we tried this?' is somehow lost along the way. A practitioner can so concentrate on each one of the steps at a time that s/he never sees the issues holistically. The emphasis on only defining a problem or measuring or analyzing precludes the 'what-if-we-did-this?' The problem is engineered to death.

In this project I'm on, the solutions proposed from the last go around made sense. I have a feeling that the stakeholders involved were change-averse to implement some of the bigger changes and didn't want to rock the boat. I also feel that our Lean Sigma group is seen as 'outsiders' or consultants who come in, do their thing, drop you the results and leave. Their stuff is good but they're done and they're off to the next thing. Stakeholders might like the analysis and agree with some of the solutions but they take a risk when implementing. If the proposed solutions don't work out in the stakeholder's favor, the project manager is left holding the bag. When Lean Sigma or management consultants leave, the project manager (who may have contributed to the development of the project) is not invested in the solution, so will be less likely to implement it (at least from the e.g. I've seen).

Again, on this particular project, I saw comments from one of the stakeholders who more or less shot the proposed solution in the foot. The Powerpoint slides depicting the proposed changes were passed around and then the stakeholder fwded the slides to his managers with many more criticisms rather than favorable remarks. It's no wonder the project stalled. What top level manager would give the go-ahead if their employees thought there were unresolved issues?
Questions:
1) Why wasn't the solution developed jointly with the stakeholders?
2) Was there a chance to rectify/address some of the concerns of this particular stakeholder?

There've been tons of issues with this particular product line; everyone agrees it is broken; The product line manager is definitely risk-averse and doesn't want to do anything drastic.

A BA should act as PM (sometimes)

2008-03-28T18:15:00.002-04:00

In our environment, in order to maintain quality of the project and make sure communication is flowing to the right people, the BA needs to step forward and own the PM space. Doing the requirements piece is essential and is a first step; the information then needs to flow downstream to all the other parties in IT. The BA is at the forefront of this endeavor. If the BA stops there and expects the PM to take care of the flow of communication, the project more than likely will come to a grinding halt; either that or it will start to flounder. The BA should either work hand-in-hand with a PM who does take ownership and is vitally interested in delivery of the project OR the BA should own this piece as well and ensure that the right people are playing their parts & on time; thus the BA is acting as PM.

The benefit of having a BA act as PM on his/her own project is that since the BA is present at the inception of the project, s/he has interacted with end-users and felt their pain, needs, requirements, etc. from a first hand basis. This makes the BA a representative of the business and the BA can really strive for what is important. The BA playing a PM role can stress the right areas to focus on in the short-term and push off the less important items. A separate, detached PM may not take these things into account, especially if s/he is not as invested in the project. In fact, having a PM involved at the outset may be too much overhead.

The beginning of the project is very vital. A BA/PM can push for a working first iteration of the software that does the most important things first; the initial software will have limited functionality and the BA/PM can even act as an initial QA resource, vetting the design and construction of the software as it progresses by doing quick checks of functionality; and in order to make sure the software is aligned with the original vision. The BA in fact is in a most unique position, especially at the beginning of a software project, because s/he can play those 3 roles: BA/PM/QA and the reason should be blazingly clear; The BA is the one who feels the client's pain and will do his/her damnedest to make sure that the client is being given what they need (if you're a conscientious BA that is)

As the project progresses, matures and gets more intricate, there will have been some momentum built and other dedicated resources can be brought in to handle specific areas of the project: a dedicated PM, junior BAs, dedicated QA, etc.

Get Developers thinking in terms of Features EARLY

2008-03-28T18:12:00.005-04:00

Developers aren't used to thinking in features at the beginning of projects. They are usually so engrossed in the details that they immediately start thinking of the tasks they need to do in order to build a piece of software.

Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen

etc.

The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.

So how do you effect this transition of language that developers speak from tasks -> features?

As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.

Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.

But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.

The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.

Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.

As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.

IT is the problem!

2008-03-20T00:06:00.004-04:00

What has slowly revealed itself over the last few weeks is pretty insane! But I had a glimmer of insight a little while ago which gnawed at me and I'm fairly certain that this is the central issue: that IT is the source of our own woes.

Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.

Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.

But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.

What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.

BA Skillset

2008-03-15T22:37:00.004-04:00

Here are some skillsets and basic tools that I feel a BA should have:

MS Office Suite

Word
Powerpoint
Excel
Access

Word & Powerpoint are no-brainers. Excel also; but more than a passing familiarity with Excel is a good thing. Knowing how to chart, use pivot tables, sort, filter, and even do some VBA are all exceedingly good things to know.

Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.

Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.

Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.

Other skills:

SQL
Communication/Writing Skills
A strong desire to play with & learn new software; being a software evangelist
An ability to filter out extraneous information and to focus on the details that drive a project forward rather than getting bogged down with too much detail: There's a time & place for everything. Sometimes getting all the information up-front is not such a good thing (your head probably won't be able to process it :)
An inquisitive nature to find out what people do & why they do it. As a BA, you need to help automate things for your customer so you need to drill into all the particular details of what they do, what actions to take when certain events occur, when they do it, how they do it, how they know when to do it, etc. Getting the whole picture will eventually reveal the grand scheme and then you will be able to propose a solution.

A balance b/w taking into account the customer's concerns vs. ability to drive a solution forward is quite key: Let's face it. If you were to build a solution that took into account EVERYTHING, you would be in a quagmire. Automating error handling for every instance of something going wrong can be fruitless. Some things should just be manually handled. A lot of people, both BAs and customers get caught up in thought exercises and intellectual games following all kinds of paths to come up with some grand solution. Implementing something like this and then debugging it can be a nightmare. Remember that you need to not just satisfy your clients but your dev & qa teams should be considered as well. If your solution solves 80% of the customer's problems, then you should strongly consider pushing that forward. The rest can be 'phase 2-ed'. When I use this phrase, it allows the customer to relax knowing we can deliver something quick in phase 1 that'll handle most cases and then we'll handle the rest later. But you know what? Many times Phase 2 never even happens because Phase 1 is completely adequate!

Strategy(ies)

2008-02-02T13:35:00.001-05:00

Some cool things to try:1) Ask employees for initiatives that have worked, that have not worked, what they've tried that they think will work well across the organization. That way, management would get ideas people have tried in their own units that have worked well and that should probably be evangelized across the organization.

2) Prototyping and front-end development responsibilities should be kept in the high cost center arenas. Integration with the back-end should be done in the high cost center. [See my previous posts for this subject beaten to death].

3) There seems to be a running theme in many of these applications we create at the investment bank. Take someone's spreadsheet and turn it into an application. Front-office users are adept at Excel apparently. Here's the progression:

They create the spreadsheet, start really using it, and get dependent on it.
They start mailing the spreadsheets all around.
They wind up with multiple copies all over the place and they get out of sync.
Then they ask IT for help...
IT comes to the rescue with a solution with 3 tiers and 6-12 months development time.

We should start looking at other solutions. If we keep following this procedure, IT is reduced to not adding any real value; we're placed in the position of playing constant catch-up. And IT is not really innovating or doing anything kewl.

Instead why don't we:
1) Train business users to use IT more wisely. There are a myriad of technologies out there. When I stop by a business user's desk, the same things strike me each time: how few applications they have installed on their box and how non-facile they are at using applications. As part of their on-boarding, they should be indoctrinated into the tech tools that are available to them; for instance, an introduction to using Sharepoint technologies; If they use an online-spreadsheet in the first place, IT might never have to build them an application at all. And even if they needed something extraordinary, we could build them a Sharepoint component to help them, for example vs. building them a whole new app. Hell, even use something like Google docs!

2) IT should get away from the mindset of creating applications from scratch. In this world of plug-n-play, we should be leveraging other solutions. That means hiring people who like to play with new technologies, with vendor products, experiment, attach the output of one product as the input to another product and integrate them, etc. We should be coding only when we HAVE to. Even the idea of taking code from one application and using it in another is often far-fetched. In reality, ripping this stuff out and using it elsewhere doesn't work so well in practice. And you usually need the guy who developed it in the first place to stick around. If he's not, good luck!

Get IT to play with experimental technologies and to prototype with them [I'm thinking of using frameworks to prototype quickly: Rails, django, adobe flex, etc].

A BA should be a RAD developer. Not!

2008-01-25T19:25:00.000-05:00

Ok, so I started hacking up some HTML using our corporate branding standards and the free snippets we have. While it was cool and easy for me to just drag a snippet into Dreamweaver and have it appear on the page without any work, there's a lot of customization involved to get it to look exactly the way I want. I just don't know enough HTML to start playing with divs, tables, spans, colwidths, etc. and putting various elements exactly where I need them, nor do I have the inclination. We really do need a full-time expert on this kind of job! It was a good exercise for me to try in any case. I now am familiar with the space, know what kind of expertise is required, how to set up other people to do the same thing, and I know enough to make a case for bringing this kind of expertise into our firm.

My philosophy is: talk is cheap; only by doing do you really know [and what I mean by know is knowing by your gut]. You just gotta experiment and try different things and see what works.

Can't commoditize the "experience"

2008-01-25T01:04:00.000-05:00

Here's something that I find interesting.

We've long ago commoditized many kinds of products. Services have been the next to go. We have BPOs happening in India, outsourcing of all kinds to many different types of firms all over the world. Some of it is good, some bad, but they're getting better. The next step up from services some say is the experience. Starbucks may not have been the ones to pioneer this, but they certainly have made it a household word. Starbucks just doesn't give you coffee (a product), or give you mere service; they've transcended into the world of experience.

So what's the point I'm making? Well, if services are becoming commoditized (and many of us are busy still making sure that goes OK), then experiences, which is next down the list, still need to remain close to the customer. We can't outsource the experience. I don't even know what that means or what it would look like! So applying this to software, we have U/X engineers: U/X = User Experience Engineers. Since the GUI is what the user sees as the entire application (users are blissfully unaware of all the middle tier and back-end stuff), we need to ensure their experience with the software is a positive one, not a traumatic one. We also need to show them that we are responsive to their needs. Thus the user experience is something we dare not commoditize and ship overseas. We need to keep this one close to our chests.

A BA should be a RAD developer. Maybe Not!

2008-01-24T21:53:00.000-05:00

So I've had some more thoughts along these lines.

After delving into the world of Dreamweaver and XHTML, CSS & Javascript [we'll see about AJAX], and talking to a real good front-end developer and senior BA, I've come to realize that my assertion about BAs becoming RAD developers is probably far-fetched. I was eager to learn it and with a bit of training and getting up to speed, I could probably create some workable pages (which I'm in the process of doing).

But I saw after my interactions with these guys that the front-end development I was thinking about is probably going to require someone devoted entirely to that task: a full-time HTML or ASP.Net front-end developer. There are just too many details that would need attending to. This is really a developer task. While I might be able to deliver workable pages (something perhaps good enough to show my users) they probably would be hacked and not very tightly coded; definitely not worthy of production. And I personally wouldn't want to go that route. My interests aren't in developing HTML pages.

So my thoughts have changed. I would say that having a BA along with a front-end developer at the high-cost centers (read: NY, London, anywhere that's close to the user) should be the new paradigm. The front-end IS the application from the user's point of view. If we get that right, everything else follows. But we need to get that right. We need customer involvement in getting there.

So if a BA and a front-end person meet with customers or users and are able to rapidly turn around the requirements into a working, clickable prototype, GREAT! You could have them iterate as much as they need to get it right. And then the front-end developer could deliver working XHTML code to the back-end developers. You can also start utilizing the front-end developer on other projects if the back-end people take a bit longer to deliver their pieces (or maybe not, depending on the methodology you're using: waterfall vs. XP for e.g.).

The main point here is that having a front-end developer to carry out RAD very close to the customer is the item that will start to foster good relationships between IT and business. The business will see that IT is more responsive because IT is able to come back in a few days with improvements in the interface that were requested. BAs will have more definitive answers and be more confident about what they're asking developers to do. And the RAD developer can deliver production-ready front-end code that back-end developers normally want nothing to do with. This is a win-win situation!

In our particular environment, we have branding guidelines we need to adhere to. The branding department has provided us with a framework of html and css (both with and without Javascript) as well as various code snippets. The front-end developer doesn't need to start up from scratch on each project. This makes high-fidelity prototyping or RAD more within reach than ever before.

A BA should be a RAD developer

2008-01-17T20:22:00.000-05:00

I had this idea today and wanted to explore it.

I've been busy reading various books on agility:

Extreme Programming Explained
Planning Extreme Programming
Project Management with Scrum
Refactoring
37signals' book: Getting Real

I've still got to go through:

Agile principles, patterns, and practices in C#
Agile project management
Joel on software

so I've been delving into the literature quite heavily. I've also been looking at Ruby and Ruby on Rails as a development platform.

I have a lot of ideas and concepts swimming around in my head and am still trying to put it all together. But I'll give it a try.

1) It is far more preferable to be a generalist than a specialist. (or to hire a generalist rather than a specialist). Why? Because you want someone who can adapt. An employee who can do only one thing well and refuses to adapt is more trouble than he's worth. You want someone who'll help out the team in whatever capacity is needed. The truth of the matter is that when you begin a new job, your day to day responsibilities may have little in common with what was originally in the job ad. Many of us may grumble about this but the truth is that the boss needs you to do something here and now and it might not be what you originally had in mind. I think this happens most of the time. I personally would want to work with someone who's eager to learn new skills and take on more varied responsibilities, who begins to get the big picture (and getting the big picture may require taking on many different tasks), and who's willing to go the extra mile to get the job done, even if it's not part of their job description. Even better is someone who actually seeks out new challenges and responsibilities; who having done their job to the letter of the job description asks, "What else or more can I do? How can I move us further along?"

A note here about this: This kind of expansion of a person's role can be perceived as threatening to others on the team or organization who are used to a system or workplace that has ascribed rigid roles and titles (most organizations in general!). Indeed, even I've had thoughts or feelings about people who seem to be "acting-up" or "showing off" or "trying to get ahead" which can breed resentment. All I can say here is that change often feels threatening even when it's for the better and the good of the team. It might be worth it to actually get involved and see how you yourself can help and adapt. It's ok to be swept along in someone else's enthusiasm and to contribute and support that person.

It's been pretty well documented that smaller software teams get much more done than larger ones. However, on those smaller software teams, members don't just subscribe to narrow, rigid roles. They wear many hats. This is exactly why a generalist is more valuable than a specialist. So if you want to build good software, make your teams more lean and make sure that the staff on those teams are willing to learn other skills.

This really struck me when I read "Getting Real". 37signals would never hire an IA (Information Architect). That is just too small a role for their team. They need people who can shine in many areas.

2) Let's face it: In a perfect world, a BA is not necessary. The basic components of a transaction are a customer and a supplier (or software developer in this case). If software developers cultivate those soft skills and learn how to communicate in the customer's language, a BA position would be extraneous. They could just do the requirements gathering themselves. This is an extreme example, of course (and that is why Extreme Programming is thus named!). However, with more outsourcing, offshoring and nearshoring, the BA position has come into its own. We do need customer representatives and SMEs that can stand in for the customer. In an investment bank arena, the BA is really the customer. The BA is in fact the customer (or customer advocate) but also represents the development team. He constantly has to wear multiple hats. Of course I still need to go back to my real customers and have what I think are their requirements validated.

In fact, this latest exercise in going to the users was very revealing. I had really developed my wireframes and prototypes very well. I put some nifty features in there that I thought would wow the users. But I go down to show it to them only to get "uh huh." or "I guess that would be nice". Not the overwhelming compliments I thought they would bestow. What does that tell me? A lot! It tells me that we can design all the coolest, niftiest features in the world, but if the user doesn't care for it, it's a waste of time. It would be great if my piece of software does everything possible with every data set but is it necessary? I realized it's very easy to get ahead of myself and over-design but without real user input to validate, it might amount to nada. That's why it's important not to design too far ahead of development. The waterfall method of stacking up a bunch of requirements months in front of development is not recommended!

3) In my current project, I'm pretty much at the point that development can start. I've got all the keys questions answered. I have wireframes. I've built a prototype using a tool, etc. Now all I need are development resources. Unfortunately the resources are busy working on something else for the next 2 or 3 months! Aaargh. One of the things I was afraid of was going to the user with wireframes, getting them excited about what we were going to do for them only to find out we can't deliver. Not a good way to build relationships.

So I'm idle and started thinking about what I could do. I'm not a fan of the functional spec document which is what traditionally would be written at this stage. However, there's no rush since there's no development team to do anything with it. I would rather do something more useful. I've started the foray into Dreamweaver and XHTML and CSS in an attempt to bring my mockups to life. Our company has code snippets for much of our internal branding standards so I should be able to design my application using those snippets. The end product could then be delivered to the developers who would not need to spend any time doing gui work. I think this would be a huge win and streamline the process. In fact, this is also a great idea for outsourcing as well.

Why not take this one step further? If Ruby on Rails really is that awesome that I can create a blogging site in 56 lines of code, why not use it to create an app for my users? Let 'em have a go at it and get the ultimate feedback! Forget the functional spec. I can hand my development team a working application AND I'll be around to answer their questions. What can be better?

This is exactly why I titled my post "A BA should be a RAD developer". It was tempting for me to sit back on my heels and do nothing, after having spec'd out my first release. But I asked myself, "Where else can I play a role? fill a need or gap?" And being a developer occurred to me. If I could get a html site up, my users would have something to play with and give me even better feedback!

So a Business Analyst's main role is to get the requirements right. The real, surefire way of doing that is getting the users an actual application to play with. Doing that quickly especially if you work in a non-agile environment is of paramount importance, especially if your culture is (as it is where I work) that IT takes forever to get things done.

I'm also looking at this method as a way of spurring management into being more forward thinking about adopting agile. If I can wow my users with useful applications and have them email me and cc my managers about how exciting it was to see the application, I'm betting that Senior IT managers will jump and want to deliver those projects.

Agility

2007-12-15T13:30:00.000-05:00

I stumbled upon the book "The Machine that Changed the World" about Toyota's Lean Engineering Processes. A comparison has been made between auto manufacturing processes and software engineering and there are now movements in lean software engineering.

I thought auto makers still did it the way Henry Ford did it. Turns out in the 1950s, Toyota revolutionized the whole thing. They were able to come out with cars 3 years before their competition and $2000 cheaper!

There is a lesson here for the software community. We need to embrace agile or lean thinking or our discipline will become staid. I think there's a human tendency to always move on to the next best thing. Work on one thing, do a good job and move on to the next. However, people don't stick around and make sure that 'good thing' is actually good. Is it being executed on a daily basis or according to plan? Maybe it needs course corrections.

I'm jumbling a lot of things in this one post so excuse the rambling. I'll sort it all out at some point.

Ideas for metrics:
1) # of unit tests written? are they growing as software is growing? Are they being executed in the nightly batch? <- refers more to adoption of TDD
2) Are we able to auto-generate documentation? [ I'm not familiar with what's out there but if we go agile and give precedence to writing code, a tool like this may satisfy those documentation hounds ]

Books

2007-11-30T23:36:00.000-05:00

I've been interested in a few business books of late:

1) Crossing the Chasm: This book is good but a little dry. I almost put it away for good a few times but I persevered and made it 3/4 of the way in. The distribution/pricing chapter got to me though. I had no idea what he was talking about. However, there are some seminal ideas in this book overall.

A lot of these techniques/ideas can be applied on a smaller scale; for instance, in my own position as an analyst pushing out a new product so we get more users.

He advocates the idea of creating user stories very similar to user profiles in usability testing.
Whole product marketing is another concept that can be applied. If I tackle the beachhead users, I need to make sure I fulfill all their needs. They'll be my references so that I can move on and win my other customers.
And of course, just deciding on the beachhead is a big decision. You need to FOCUS on which segment you want to win. You can't tackle all your customers at once.

2) Execution: The Discipline of Getting Things Done
I haven't yet read this book but it's on my queue. Even before I heard of the book, it came to me in a flash that the single biggest obstacle to success is lack of execution. Every Tom, Dick & Harry has a new plan, a new strategy that if they get their way and implement, then things would work out. But give Tom, Dick or Harry that chance, and you'll see 9 times out of 10, they'll kick the strategy off, give a few high level commands and assume it's done. They'll then move on to other areas where they can tout other high-level strategic initiatives. Tom, Dick & Harry have no follow-through. They think their jobs are done and move on to conquer the rest of the world. The sad reality is that without the actual will to implement, enforce and measure, their strategies end up being only mere words and now Ray, Jim & Frank are waiting in the wings to kick off their own set of initiatives. And here we go again...

Culture of Discipline

2007-10-13T23:51:00.000-04:00

Title stolen from a chapter in Jim Collins' book "Good To Great".

I had arranged for a demo of Agile development to our team and I thought maybe it was something that we could employ. However, to my dismay, one of our software practitioners (in fact he is one of the development managers) didn't like the process; he called it micro-management and claimed that his engineers would kill him if he tried something like that with them [in jest of course].

The process that was demonstrated was called SCRUM and it employs meetings every day asking developers what they did yesterday and what they're doing today. Moreover, this particular process asks for developers to enter their time spent doing development on a daily basis. It definitely involves more careful monitoring of people's time. However, this is an effective scheme for determining if software schedules will be met and for averting disaster. The bi-weekly or weekly status meetings don't cut it anymore. I can understand his point of view. I used to be a developer myself and probably would have hated to determine how long a task would take or be constantly asked how much time I spent on something everyday. [A little bit of "Don't tell me what to do"]

This needs to change if we're going to ever get good at software management. This is a culture change in the way of treating software engineers and asking them to change their behavior, i.e., to become more disciplined. As a software engineer, I was arrogant and cavalier. I prided myself on being an expert at C or C++ (or whatever it was I was doing) and any company should be glad to have me and my expertise. If I need to take as long as I took to get something done, then that's how much time it should have taken. Or if something wasn't done that should have been done, I was busy doing something else that was just as (if not even more) important. My time was my own; I didn't have to tell anyone what I was doing; and for the most part management didn't care. If I got things done a day early, no one had to know about it and I would surf the web and take it easy the next day. But that kind of attitude isn't how you build great software nor a great organization.

Micro-management is a dirty word. No manager probably wants to be called that. It's a death knell to be referred to as one. However, the truth of the matter is if you were to form new habits, you need to act as one. If you're losing weight, until you form the habit of watching what you're putting in your mouth, you will not lose weight. You need to micro-manage what you eat. If you're learning a new skill, you need to pay attention to the minutiae of each motion (e.g., swinging a tennis racket). Similarly, the same goes for management. If you're going to introduce new habits (or processes) within your team, you need to buckle down and enforce them until they become a habit. You need to micro-manage. If you're going to kick off a new process and expect your team to follow it, you're going to have to monitor and micro-manage them and quickly correct errors. This is a fact of life. Don't let the fear of being called a micro-manager deter you!

In fact, one of my most memorable experiences being 'micro-managed' was at a start-up company. A new senior executive had joined at a time when our product had fallen behind. This new exec quickly set up daily early morning meetings with key staff and a list of the issues. It was almost like a SCRUM meeting. He wanted updates on each issue and what progress was made since the previous day. At first I considered the meetings a pain. [I don't want to be at the office by 8 !!] It was intense, being in those meetings. You had to own up! And you knew what was expected of you at tomorrow's meeting. But after a while, as the issues were closed, one after another, and our software became mature, we really became cohesive as a team/company and felt proud that we were pulling together to put out a quality product. We eventually had a great product ready for the market. This guy did what his predecessor didn't do. His predecessor was hacking away at the weeds whereas this guy knew what needed to be done and did it. No surprise that he is now a Senior VP at IBM.

In fact, to really build an effective organization at all levels, that "micro-management" ethos needs to be practiced by every individual in the organization. Each individual needs to be disciplined enough to carry out his/her duties to the fullest. Jim Collins states: "People in the good-to-great companies became somewhat extreme in the fulfillment of their responsibilities, bordering in some cases on fanaticism". I liken micro-management to being present in each moment. If you're present in each moment of your life and fully engaged with what's going on, then you will fulfill your responsibilities. Or you will speak up and address something when it doesn't make sense and so on.

Effective Software Managers

2007-10-13T21:15:00.002-04:00

Here's a link to a little blurb on being an effective software manager:
Effective Software Manager Blurb

and here's a link to the article the blurb also references:

What Makes an Effective Software Manager?

The author in the first link writes about his manager getting rid of ineffective people. This is really interesting because it's exactly the first thing Jim Collins writes about in "Good to Great": First, get the right people on the bus!

I also feel "Making the Call" [referenced in the two articles above] is incredibly important. I've found 'making the call' and 'taking ownership' go hand-in-hand. I'm seeing real-life examples where people who don't do so lead their employees in circles, running only to stand still and never without any sense of completion.

An example:

There is a service provided to us by an outside party and the contract was never signed. The service was executed nevertheless and the first quarter invoice for 2007 is still yet to be paid. Myriad attempts to get this invoice paid has led nowhere. I'm not sure who was responsible for dropping the ball. I do know there were many attempts by IT to pay the invoice. In addition, the contract was never signed for this service and this has been outstanding for almost a year. An email that I had sent out regarding the matter was never responded to. It would be amazing for a change to hear someone say, "OK, great. Let me look at that contract, sign it and hand it right back to you" and for them to actually do it. Instead, unreturned emails and phone calls are the norm. If my business user would 'make the call' or 'take ownership' this would make mine and many employees' lives easier. Instead, the issue gets buried until the next go-round.

I think in an environment like the bank where IT serves its business users and IT has traditionally acted subservient to the business, making the call is especially important. Many IT people I've seen don't want to challenge their business users and state their terms. Instead, they're led astray by business users who have no IT knowledge. I've actually found that when I grab the reigns and state unequivocally what the options are and what the challenges are of each option, then usually the business will comply. After all, we serve their interests. Why shouldn't they trust us? In fact, IT can be in a position where we can actually LEAD the business. However, when we are too eager to please or afraid to be clear about our intent, communication breaks down and we (IT) can be sent off on wild goose chases; goose chases, we might be resentful about, because we weren't clear from the get-go and because we were afraid to be straight with our users.

Metrics

2007-10-06T19:51:00.000-04:00

We use MQC (Mercury Quality Center) to store our defects and enhancements. We have about a year's worth of data in there and no one has thought to look and see what it tells us. I recently undertook such an effort. I export ALL defects/enhancements from MQC into an Excel file which is then parsed by an Access Database. I then wrote various queries to examine the data.

Here are some metrics that I want to examine after each release of our software to see how we are doing:

1) # of Outstanding Defects as of completion of this release ; broken down by severity and what version they were found in [to see how long they've been lying around]

2) # of Outstanding Enhancements to be implemented; broken down by priority and when they were requested [to see how long they've been lying around]

3) Breakdown of Defects/Enhancements for this latest release by Component to see which component of the software was touched the most.

4) Average [Mean, Median, & mode] Time to Fix a Defect [Critical, High, Medium, Low] until now

5) Average [Mean, Median & mode] Time to Implement a New Request [Critical, High, Medium, Low] until now

NOTE: If we apply Metrics 4 & 5 after each release, we can see if the average decreases over time to see if we're getting faster at delivering fixes and enhancements.

These metrics are pretty simple but will give us terrific information on where we are and what we need to work on to improve our process.

Support from the Top

2007-10-05T08:30:00.000-04:00

If Bosses, Line Managers & PMs made it clear they want to see:

1) Burndown charts where they can see the progress to date vs. what was originally planned. And that they expect to see progress every day. This means that even if the manager doesn't have time for a status meeting today, if they wanted to see one s/he should be able to. It should be updated daily in accordance with what was accomplished. Management needs to catch errors early and to see if a project is going off-course in order to be pro-active.

As with daily scrum meetings, why not have a scrum-like managerial meeting where a burndown chart is presented and progress to-date is discussed, progress to-be-made is discussed and obstacles are presented?

2) Working software after each iteration! This is the only true measure of progress! Managers should ask that the software be demo'ed after each iteration.

more projects would be delivered on-time and on-budget! More users would be happy.

Some Agile Practices

2007-10-03T19:22:00.000-04:00

Agile Practices that I'm thinking of implementing and as adapted to the environment I work in.

1) Have daily meeting for 10 minutes; Being agile requires open communication; everyone should know what's going on all the time.
Each person states:
a. What s/he accomplished yesterday
b. What s/he's going to do today
c. Any pain points/issues/obstacles

2) Have a process improvement meeting every month or even bi-weekly in the beginning
a. Figure out what's working/not working in the process and make adjustments

3) The BA should be available as development proceeds in each iteration to answer questions that come up and to test. This happens naturally in practice anyway. Much as we prefer a complete spec up-front (which few people read anyway), we should be honest about what the actual process is. Do we want to spend time developing the best spec ever up-front or proceed with Just Good enough requirements and start coding so we get working software?

These questions can be asked in a one-off basis (developer calls BA) or during the short, daily status meeting.

4) Use Burndown charts rather than project plans to track progress. Burndown charts are effective and especially look good to management because you can compare your original estimate to how you're actually doing. You can absorb all kinds of info including your 'velocity', where you hit bumps in the road, etc. Traditional project plans do not offer this because you just keep overwriting the same plan over and over with the latest dates. The n-th plan, after it is updated, looks like it was supposed to happen by design when in reality, you made it conform to the current status of the project. There is no way to compare the n-th plan to the 1st plan to show you how close you were to your estimates. And if you can't do this, how are you going to improve your process? Process Improvement depends on measurement and re-measurement! [I know people will object and say MS Project allows you to do such and such; and this might be true but to date, I haven't found anyone who uses this feature.]

5) Iterative Development and scheduling by feature delivery rather than Initiation, Definition, Design, etc.

6) Get estimates based on time to implement features rather than Initiation, Definition, Design, etc. These estimates would likely be more accurate and something developers can give and live up to.

7) Deploy prototypes and let developers have a go at them to give feedback so you can make it even more bulletproof and to also advertise to them what's coming. Prototypes help developers get familiar with upcoming changes and new features and will enable them to give better estimates on implementation time after playing with a prototype. Prototypes also act as requirements specifications in and of themselves. Rather than have a developer wade through a huge specification document, s/he can fire up the prototype and see the actual behavior demonstrated! A prototype is worth a thousand pages [of requirements documents]!

8) After incorporating feedback from the Dev team, I would go show my users. The prototype needn't do everything. It's a good idea to storyboard a typical scenario and walk the user through it and paint a picture. Picture a child enraptured by a parent telling a story. You want to fully engage the user with a prototype and have s/he contribute meaningful feedback.

Types of Projects

2007-09-30T20:21:00.001-04:00

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?

2007-09-30T19:51:00.000-04:00

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

2007-09-30T19:23:00.000-04:00

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

2007-09-30T19:15:00.002-04:00

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

2007-09-03T23:43:00.000-04:00

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

2007-09-03T00:23:00.001-04:00

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

2007-09-03T00:11:00.000-04:00

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

2007-09-03T00:00:00.000-04:00

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!

2007-09-02T23:05:00.000-04:00

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