Don't bring me problems; bring me solutions!

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

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!

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

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

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

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

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?

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

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

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.