Ask Questions, Get Answers (And check out the link at the end!)

This week, I have been contemplating the power of asking questions.


So much goes unsaid in projects, and within project teams. Assumptions are made about requested features, technical approaches, architecture, data policies, and even communications.

How many times has your internal dialog gone something like this:

“Someone else probably knows what she means by that.”

“He’ll probably send out an email to the stakeholders about that.”

“That means I need to write a script to handle that.”

“Selection tool? That means I need to implement a radio button menu.”


How many times has that internal dialog been wrong, and you find that out the hard way, after your assumptions take you down the wrong path?

How many times could the above situation been solved if you had asked the right questions up front? How much more information and insight could you have gained by probing deeper, by expressing your concerns, by asking Why?


I’ve always been one to ask a lot of questions, and have never shied away from it. But I still fall prey to the assumption-making sometimes.


Today I invite you to join me in making a conscious effort to ask more questions. Don’t make assumptions. Ask, and you might be surprised at what you learn.


In the spirit of asking questions, I was just asked a bunch of them as part of an interview for TeamPulse, which is a company that develops an “all-in-one” project management software tool. (Check them out!)

I have to say, it was so humbling, exciting, educational, and awesome to be asked to contribute to TeamPulse’s website.

It was the perfect reminder of the importance of asking questions, since it sometimes takes getting asked a question to reflect on some things that you just assumed you knew about yourself!

Check out the interview, and let me know what you think!


And of course, please ask me any questions you might have – practice what I preach! ;)

Want Results? Get Uncomfortable

It’s May.
We’re almost done with half the year, and I haven’t stuck with my publicly declared commitment to be more regular with my writing.
This is not an apology, though.
It’s a declaration of peace, made from me to me, and maybe it’s even a bit of a pat on the back.
Why pat on the back, you ask? Because this year I’ve had to adapt to what has been the equivalent of getting on one of those roller coasters at an amusement park that you’ve never been on before but you get on anyway assuming you’ll be FINE because how different can it be from all of the other roller coaster rides you’ve been on before in your life?
Then the roller coaster flips you upside-down as you head backwards down a spiraling track and you realize: this is NOTHING like ANYTHING you’ve ever been on before.

So, how are you all?
Some of you I’ve been connecting with on Twitter via the #PMChat,  #pmot, #agile or #scrum hashtags. Others of you I’ve been connecting with in person or through email, and some of you have probably been on your own roller coaster rides.

There’s been an underlying theme to this year that I’ve wanted to share with you all time and time again, and it’s one that I really truly want you all to take to heart:

In order to see results, you MUST get uncomfortable.

Whether you are looking to see a change in your career, get on a new growth path within your current career, or even see a physical change in yourself, you must get uncomfortable to see the results you want.

By “get uncomfortable”, I don’t just mean “step outside your comfort zone”. What I’m talking about can’t be wrapped neatly into 5 words and presented as though it were an exercise in pacing yourself and moving forward one step at a time.

I’m talking about flinging yourself straight out of your boundaries and limits and landing squarely in the middle of something that may freak you out so enormously that you feel like you have no way of ever regaining your footing and standing up again.
I’m talking about consciously removing yourself from what you know and placing yourself in situations that give you that sinking feeling in your stomach when you look up and realize you’ve never seen a mountain that huge before, and have no physical proof you can find your way up.

Except you will. Because your determination and abilities are greater than you ever knew they were, and when you take the first few steps up, realize you can keep going, then end up traveling a few miles towards your end goal, you will wake up one day feeling ridiculously sore but ridiculously giddy to get back at it and keep going.

This year I have found myself getting into situations that I feared I would not know how to navigate. It seemed to all come together and manifest in different areas:

Physically, I decided my routine had become stale and failed to provide me with real results or any kind of real difference or challenge. I started a crazy military-style bootcamp program that I initially planned on doing only for a few weeks.
For every day of the first week, I had to wear a 30 pound vest while doing all the same exercises the rest of the class was doing. By the third day I was shocked that I hadn’t yet hurled my guts out as I hurled out every curse word I knew (in multiple languages). My body was in some kind of shock, and I had never felt so worried that I would just fail; that I would just not be able to make it through the hour without quitting.
But I came back for the next 3 months, and got into the best shape of my life. (I recently stopped going to bootcamp because it was time for me to fly away and leave the security of the nest, and figure out how to stay challenged and fit on my own.)

Career-wise, I moved from the security of being a traditional full-time employee of a company, where there was a clear career path, a pretty stable (for the most part) cast and crew, and a known subject matter to being a consultant. I suddenly had to define who I was, who I wanted to be, and then figure out how to take control of how far and where I was going to go. It’s no secret that I am passionate about Agile Product Development and about helping organizations learn how to be effective and produce results using agile methodologies.

I decided when I made this move that I was going to be true to my beliefs in this role – which ultimately means not being a Yes woman, and (maybe frequently) delivering messages that a client might not want to hear. As a consultant, that comes with a higher risk of being told to leave the client’s offices and never come back because, well, there are no strings attached. They have no obligation to keep me around. That scared me. I’ve stumbled a few times and realize I will again, but when things go well, it makes up for the stumbling in such a big way.

I recently traveled and spent an intensive week at a client site to help them with some issues they are having as part of their adoption of agile methodologies on one of the largest projects (really a program) they have ever undertaken. These issues are normal and natural as an organization attempts to change the way they work and view things in such a big way, especially when combined with the fear of “Will We Ever Get There?”

One week is not a lot of time. I had so many questions and a growing anxiety about whether I would be able to do a good job, provide REAL value, and really HELP them achieve their goals. I kept having flashbacks to the image (and queasiness) of trying not to puke my guts out while doing burpees with a 30 pound vest on. I also woke up at 4:30 a.m. for an entire week.

But it got done. And some of what we did together while I was there was extraordinary, mostly in that I saw a team coming together with renewed hope and best of all, I saw the question changing from “Will We Ever Get There?” to “We Believe We Will Get There – So What’s The Best Way To Build This Together?”

There’s still work left to do, but that first week is over. Now I can take off the 30 pound vest and keep going.

My next goal: Getting myself into my bed and sleeping past 4:30 a.m. (Hey, not all goals have to be difficult to achieve!)

Putting a Face to a Name – Personas for Better User Stories

A number of years ago, I worked in an organization that developed and released highly successful consumer products. I was (and still am) convinced that a part of that success can be attributed to this organization’s thorough (can we say OCD?!) analysis and definition of their target end-user.


People, when I say thorough, I mean thorough. Like me scrubbing those little edges between the kitchen counter and the stove with a toothbrush and a flashlight THOROUGH. (Hey, no judgement!)


For EACH variation of EACH product released out into the market, there was an elaborate definition of the target user (i.e. Persona) which included their age, marital status, family size, interests, and yes, their name.


I have to admit, at the time, I couldn’t help but think that this was overkill. Come on, did I really need to know that Supermom Sally had 3 (vs. 2? vs. 4?) kids and loved scrapbooking?

(I did love finding out that she multitasked like a pro and kept everything under control while maintaining a cool exterior and perfect hair. My kinda woman.)


So, although I did find value in understanding the different types of end-user in a general sense, it was a stretch for me to buy into the idea of needing to know their life story in order to make product and feature-level decisions.


Fast-forward to today, where requirements are now user stories, and the user is the center of my project world. Our success hinges on either (at a minimum) or both (ideally) of the following:

  • Our ability to get into the head of our target user and understand their needs, even those they might not know they have. (By the same token, we need to be able to detemine when something that the user might think is a need is actually, well, not.)
  • Our ability to listen to our target user when we have the opportunity to get their input and feedback throughout the life of the project.


Guess what I’ve found to be a great tool in achieving the above?


A well-defined, clearly articulated persona definition for the end-user.


Now, does that mean we need to determine how many kids Techy Tim has in order to be able to figure out whether he needs a drop-down or a checkbox?
Probably not in all cases, but in retrospect, for the industry I was in years ago when I was first exposed to elaborate persona-creation, it was probably a good idea.


Moral of the story: There is power in putting a face to a name. For better user stories, spend a little time to get to know your target end-user and create personas that your team can refer back to.

They will both (the end-user and team) appreciate you for it, and the proof will be in the success of your project/product.

Extra! Extra! Agile Headline Exercise Gets the Ball Rolling

A few weeks ago, I had the pleasure of facilitating two days of product/release planning combined with  user story gathering (although I like to call it user story “exploration” since that’s what it felt like.)

I wanted to start things off with a product visioning exercise/ice-breaker to get things going and to warm people up.
Although we gave people a couple of options for the product visioning activity, everyone ended up choosing the “Headline News” exercise, which I learned at Agile 2012 from Jimi Fosdick, Agile Rockstar.

(Note: Jimi does not call himself that, but he should. So there.)


The Headline News Exercise

In case you aren’t familiar with the “Headline News” exercise, here’s the gist of it:

  • Have people self-organize into groups of 3 or 4 people. If people are reluctant to get this process started, encourage them to walk over to the complete other end of the room and find 2 or 3 other people to work with.
    Get people out of their comfort zone!
  • Give the groups about 10 minutes to work together on the following:
    • Envision the project/product after it has succeeded and been released to the world
    • Imagine your project/product has made the front page of the news/relevant industry publication
    • What would the headline say? Include words/phrases that describe how your project/product has changed the marketplace/made a difference/is different than everyone else out there. Think especially about how your end-user is impacted by your project/product
  • At the end of 10 minutes, (or when you sense/hear the activity level start to die down), ask each group in turn to select a representative to read out the headline and provide an explanation of why certain words/phrases were used.

(Note: You could also do a variation of this exercise where people create a short script for a feature story for the evening news. At the end of the exercise, you have them read their script aloud.)

Within minutes of getting this exercise started, the room went from a group of 30+ people who weren’t sure exactly what they were there for, with a slightly glazed-over look in their eyes, to a buzzing beehive of activity and noise.

Music to my ears.

I literally had to stop myself from jumping into the middle of each of the groups and going “YOU GUYS ARE AWESOME! ISN’T THIS FUN?!”


The Headline News Exercise Bears Fruit

At the end of the Headline News exercise (which took only a few minutes), we had a basket filled with the following fruits, giving us a great head-start to the rest of our 2-day session:

1) Energized and engaged stakeholders
2) Key words and phrases that would help build the project’s success criteria
3) An objective description of the project/product’s end-goal and most important features
4) A subjective look at what would make the stakeholders/team feel proud of the end-product
5) A vision for how the project/product was supposed to impact the end-user


What Next?

Once we had established the product/project vision, we started down the path of getting to know the end-user better. For what better way to start to write stories for the user than to get to know that user on a personal level?

But that’s a story for another time.


If you are in a position to help kick off a project or product planning session, give the Headline News exercise a try. Don’t underestimate the power of allowing people to collaborate on finding the language to express their collective vision.

Resilience: The Art of Bouncing Back

As I sit in front of my TV, mesmerized by the magic of Olympian athleticism, I can’t help but think about what it took for those athletes to get where they are today.

Years of training, learning, injuries, winning, and, perhaps most importantly (yet also most undervalued), failing.
Soul-crushing, devastating, painful failures that can break a person’s resolve and lead to giving up on one’s dream.


The difference between being average and being someone who succeeds at achieving their goals (and perhaps even makes it to the Olympics!) is what comes after failure.

Instead of giving up, elite athletes find a way to pick themselves up, brush themselves off, and give it their best shot all over again.


All of us have the ability to be elite in our jobs/fields. Becoming one of the best at what we do comes from possessing passion, a deep desire to succeed and serve others with our work, and the ability to bounce back even after looking failure straight in the eye.


In life and in managing projects, it’s how you deal with failures that can define your success the next time around.


The next time you hit a snag in the road, whether in life or in one of your projects, try following these steps to come back even stronger:

1- Acceptance:

Accept that you may have failed, or been part of a failure. Especially if you are used to winning, or always being on top, acceptance can be difficult. Your first reaction may be to fight, deny, or even project failure onto others.

When faced with failure (whether in the form of a project that’s gone completely off-track, critical feedback on your work performance, or in a personal relationship), take a step back and try to separate yourself from the event.
Rather than beat yourself up, wallow in the misery of failure, and get stuck, remember that you are not the failure you are facing.

Accept that there may be some validity and reason to what is happening; perhaps you didn’t pay as much attention to a certain phase of planning your project, perhaps you were so focused on the details that you lost sight of the big picture, perhaps you were just insensitive to someone’s needs.

Accepting failure takes courage, grace, and humility.
Congratulate yourself on making it through the hardest part of bouncing back!


2- Analysis:

After accepting the failure, do some (but not too much) analysis on what went wrong. Was it an oversight that you can pay more attention to in the future? Was it a behavior that you weren’t even aware had an impact on others? Was it simply lack of skill in a certain area?

One of my favorite terms in life and in project management is “root cause”. There won’t always be one root cause that you can pinpoint (how awesome would that be?), but it’s always a great educational exercise to work through the layers as you try to find one.


3- Damage Control:

Figure out how you are going to right your wrong. It’s that simple. What steps can you take to immediately make things better?

Can you identify someone you really should apologize to? Can you send an email to your project team showing how thoughtful you’ve been in accepting what went wrong and figuring out why it happened? Then do it.

Demonstrating your ability to handle defeat with maturity and a forward-thinking mentality will make you stand out from others, give you credibility, and perhaps even provide you with a second chance.


4- Remediation:

Now that you have it, take that second chance by the horns and OWN IT! You’ve done the hard work of accepting and analyzing the failure, now determine what steps you need to take to ensure you don’t make the same mistake all over again.

What things have you learned from this failure that you can apply moving forward? Once you’ve determined the steps you need to take to move from failure to success, write them down and solicit feedback if possible!

For example, if your failure involved someone else or even an entire team, choose someone who was impacted and who you trust, and run your plan by them. They may have some ideas on how to improve your outcome the next time around that you didn’t think of. At a minimum, they will have a greater appreciation for you and your approach.


If you want to end up in the winners’ circle, remember this:

Failures should not define us as people, but if we are deliberate, we can ensure that our failures help us become more resilient, and ultimately, define our path to success.

Project Managers on TV?!

This week, I was on TV!


Project Management TV.


Yep, you heard right.


Project managers, coming out from behind their gantt charts and project plans, and talking in front of a camera. (Ok so they were webcams, but hey, it’s still something!)

The topic was “Doing More With Less”, which is something many (most?) of us have been hearing at work lately.

Check it out, and if you make it to the end, you’ll see a little surprise tidbit I share about how I stay sane.


Enjoy, and make sure to check out upcoming episodes of PMTVPro!


PMTV Pro: Doing More With Less

Do You Get Involved in Tasks?

I used to love getting this question in interviews, because I truly and passionately believed in my answer:

How do you motivate teams of people when you don’t have any authority over them?


At this point, my face would break into a big smile, and I would start describing my three-pronged approach:

1- Food (Kidding, but really, I’m a much happier person when I have food in my belly, so why wouldn’t others be, too?! For serious. Just ask my family, they’re more than happy to share horror stories of me turning into a low-blood-sugar crank-monster.)

2- Personal Ownership: a.k.a Having a stake in the outcome

3- Sharing the Load: Demonstrating a willingness to roll up my sleeves and get involved in tasks


And this is where the project management/team leadership cookie (the one I baked for prong #1 of my three-pronged approach) tends to crumble.


For managers who believe in multitasking as an asset, I was singing their song. They were hiring a twofer (or threefor?)!

I could project manage AND write a database stored procedure AND do quality assurance testing.


Recently, though, I’ve engaged in some interesting debates regarding whether or not an effective project manager/team leader should get involved in tasks.


I understand the theory and reasoning behind it.

In order to stay focused on the big picture, and in order to stay effective as a leader, you shouldn’t interfere with the work of the team. There is risk involved, since you might not be the most qualified to take on specific tasks.


There could be a conflict of interest too. As a project manager, it’s easy to focus on wanting to get the work done and completing your project on schedule, and therefore (consciously or sub-consciously) not focusing as much on finding bugs when testing, for example.


So, on an intellectual level, I understand the argument that it’s better NOT to get involved in tasks, and to let the team do what it does best.


But on a personal level, I can’t bring myself to say that in every single case, staying hands-off is the best policy. I find it hard to be working with a team that’s caught between a rock and a hard place and not get involved, especially if there are outstanding tasks that relate directly to my background.


Maybe it’s my sense that to really be able to bring out the best in a team, I have to be a part of the team.

Maybe it’s my desire to want to help.

Maybe I’m wrong.


To clarify, I don’t always get involved in tasks. It’s simply not practical, nor is it in the best interest of a team that’s learning to work together, do their best, and be highly productive no matter who’s leading them.


But sometimes, I do. I roll my sleeves up, find a pain point I know I can help relieve, and get to work.


What do you think of getting involved in tasks? Do you do it, or do you steer clear?


Mindshift: 4 Reasons to Celebrate the Devil’s Advocate

There’s one on every team.


They sit there, quietly listening as you (and others) discuss the best approach to a problem, the criticality of the latest discovered bug, or where to go for your next team lunch.


Then, like a predator pounces on its prey, they find a point of entry into the conversation, a way to go against every other argument made, and a way to rip the discussion to pieces.


This, my friends, is The Devil’s Advocate













Sound familiar? Does someone (or maybe a couple of people) immediately come to mind as your team’s devil’s advocate?


How do you handle your devil’s advocate?


Do you avoid directly addressing them during meetings or conference calls?

Do you breathe a sigh of relief when they decline your meeting requests?

Do you subconsciously put up a mental block when they start talking, focusing not on the content of what they’re saying, but on wondering when they’re going to STOP talking about all the holes they’ve poked in your approach?

In these moments, do you find yourself planning your escape route?


Well, today I’d like to invite you to STOP DOING THAT.

Because in reality, the Devil’s Advocate is one of your (and your team’s) most valuable assets.


Oh yeah, I said it.

Your Devil’s Advocate is Your Friend.


Why? I’m so glad you asked, because I’ve been thinking about the answer to that question!


Here are 4 reasons to celebrate the Devil’s Advocate:

  1. Diversity of opinion: Teams that agree on everything are probably not very effective teams. Diversity of opinion brings life to your project, your team, and your solution.
  2. Unique perspective: The Devil’s Advocate usually has a unique perspective, which can be the result of a different background and experience, or simply a different way of thinking. This usually results in a unique approach to solving problems and approaching challenges.
  3. Confidence: Nothing can help you build confidence in your decisions as much as coming out of a heated debate with the Devil’s Advocate where you clearly, strongly, and effectively lay out your case with evidence and conviction. Yes!
  4. A break in the monotony: Let’s face it, projects can sometimes seem to go on and on and on, and meetings can start to run into each other and feel like one big, long torture session. (Hopefully not, if you’ve taken the advice from the Stop Doing “Whatever It Takes” post and eliminated those unneeded meetings!). Having someone there who mixes things up a bit can be a welcome break from the monotony, and an opportunity to observe your team’s dynamic.


So, share with us! Do you appreciate your team’s Devil’s Advocate? Can you shift your perspective, and start to see them as a resource, rather than a nuisance?

Would love to hear from you!


Project Leadership and Entrepreneurship

This week, I had the amazing privilege of being the guest tweeter on the weekly #PMChat discussion.

I can’t begin to describe how much fun I had, answering questions, debating, and engaging in an intellectual tweet-dance!

The topic of this week’s #PMChat was one I recently wrote a guest blog post about on Robert Kelly’s blog, titled “5 Ways a Project Leader is Like an Entrepreneur”.


For most people, the words “entrepreneur” and “project manager” conjure up very different images. This was evident during our tweetchat on Friday.

At some points, the discussion was intense (as expected with a group of driven project managers who make things happen!), and people made some compelling arguments regarding whether or not entrepreneurs and project managers could be considered similar.


In all honesty, I couldn’t have asked for a better debate. Part of my goal was getting project managers to think of themselves (and other project managers) in a different light. Part of it was also to bring to light the idea that leadership and innovation do not live only at the top.


If you’re interested, you can listen to my interview with Robert Kelly and Rob Prinzo, in the pre-game radio show at the link below. It was great connecting and talking to them, and I look forward to upcoming editions of #PMChat! (Here is the link to the schedule for upcoming PMChat topics and guests.)


Listen to internet radio with KellyProjectSolutions on Blog Talk Radio