pmStudent

Working on a large aerospace project the traditional requirements model applies. On my project user stories have not been used before to my knowledge.

Coming into this project after requirements had already been defined, I find that those requirements are somewhat lacking as a good description of what our software is supposed to do. They also do not function well as a springboard for further conversation. Now that I've been on the project for a while, I am ready to really start digging into using user stories and other agile concepts with my teams.

So far with one of my smaller teams we have been using user stories but not tracing them directly to requirements.  This is worked out pretty well for the smaller team, but with a larger more complex project this probably won't cut it. So, now I am starting a new release with one of my project teams and I will be creating a module in the requirements management tool that we use.  I will then trace the user stories to the requirements.

I have never done it this way before. In the past, I have always done either completely agile development with user stories and use case scenarios as the primary means of understanding what the customer needs or I have used a straight work breakdown structure and requirements framework.

The current plan is to not configuration manage the user stories at the same level we do our software requirements. With the user stories my team will essentially be the configuration management board, along with the customers for the specific functionality that we are developing. We have many customers including other software development teams, science users, and the mission operations personnel that will be using our software.

Do any of you have experience implementing user stories in a waterfall environment like this? If so I'd love to hear your suggestions and experiences on the topic.

Share this with your network

Today I'd like to share a few a success story that I've had recently with using kanban as a method for managing projects. In May of 2010 I decided to use this thing called kanban with one of my smaller project teams. The team was really excited about the idea although a little wary as well. I had only been there for about a month and already had a reputation as someone lets to try crazy weird new things.

It's been a little slow getting up and going with kanban and all of the concepts that come with it but I'm really happy with where we're at now. We finished out our first release using a kind of hybrid approach to kanban trying to not go to deeply into value stream mapping and user stories and some of the other concepts that come along with agile or kanban.

Value Stream Mapping

At the beginning of our second release we sat down as a team and figured out what our value stream looks like. A value stream is essentially just a series of toll gates that your project work moves through where each step adds value to the end product. It's a great way to understand the way that you're currently functioning as a team, and a visual way to understand how you could improve the process flow by which you produce the product.

Continuous Integration

In the process of developing our value stream we figured out doing things in real time is going to save time overall. For instance, with documentation, we used to wait until close to the release time where we were going to testing in order to hurry up and get all of our documentation done. I think the general assumption we had was that we didn't want to waste time doing documentation until we were finished coding because otherwise we may have to change the code and then go update the documentation again. In reality, working this way has saved us quite a bit of time.

For one thing the developers don't have to go back into their code and go through it again to try to remember what the heck they coded back three months ago. There is a lot of waste to get injected into a project when you wait so long between the time that you do the work and you try to document the system.

Focus

Another major benefit we found from kanban in general and value stream mapping specifically, is the focus it helps create when we are working on tasks. With kanban a very important premise is that you limit the work in process. By mapping the value stream and making sure we only have one or two user stories or tasks in work and any given time, it helps protect the team from bad multitasking and getting distracted.

The kanban board also makes progress and status reporting extremely visual and easy to manage. In combination with the daily standup meetings that I started back in May. It has really improved our communication as a team.
 

Ahead of Schedule

Now, I'm happy to report that we are over a month ahead of schedule on our second release! The original baseline schedule was made at a time when we didn't have a lot of these practices in place that we now do. I have three other systems to experiment with, so the experiment will continue. But so far I'm really loving what kanban, user stories, daily tag ups, and continuous integration are doing for us.

Share this with your network

The first question I ask of students when I do career coaching is whether or not this is even the right choice for you.

Here is a primary consideration if you are considering a career switch into project management.

Individual Contributor?

In what role do you get the majority of your satisfaction?  Contributing directly in an individual role or by leading others who are contributing directly?

Make no mistake, the project management role is about facilitating the real work that is producing a new product or service.  When I point to the result of something my project teams have produced, I say "this is what my team did", not "this is what I did."  I guided my teams to create the product, I didn't create it myself.

If you are someone who derives a ton of personal satisfaction from how well you personally created something, the individual contributor role is probably for you.  If you want to be a manager, project or otherwise, then you need to be able to derive your personal satisfaction from working with people and their accomplishments.

The Goal:  Love What You Do

Have you ever had a manager (project or otherwise) who just didn't seem like they loved what they do?

Of course, we all have!

If you do not have a passion for working with people and deriving your satisfaction through them, you probably should not be a manager of any kind.  You'll end up being on the extreme:  a micromanager or an apathetic manager.

Now, an ex-programmer who is now a manager but still loves to program is not necessarily a bad thing.  As long as they view the objective of their management role and how to derive satisfaction from it appropriately, this is fine.

It becomes a problem when they want to write big chunks of applications themselves because "no one else can do it like I can." and so forth.  Or in some cases, the job becomes a meaningless cycle of paperwork because they just don't get jazzed by developing people, enabling team communication, or removing obstacles to help their teams succeed.

Do you have the DNA of a project manager, or an individual contributor?  Neither is better or worse, they are just different.

Share this with your network

Sometimes, we equate things that don't really mean the same thing.  Competence requires experience, but experience does not equate to competence.  I can infer experience from observing competence....but I can not accurately infer competence from a list of positions you've held.

Experienced ≠ Competent

We fall prey to common cognitive biases which lead us to believe that if someone is experienced, they are therefore competent.  It can trip us up when hiring for our teams.

Another aspect of this, and the more pernicious one, is that new professionals may lead themselves to believe that once they have some experience under their belt they will have 'made it'.  Complacency can set in after you've landed a job for instance, because you've tricked yourself into believing that simply holding that position makes you more valuable.

Certifications and Degrees ≠ Competence

The same goes for certifications and degrees.  Many people believe that holding a particular credential implies a level of competence.  Unless the credential is formulated specifically to assess competence, no such correlation is warranted however.  Organizations fall prey by hiring people and screening them on the basis of particular certifications or degrees.  Individuals fall prey by thinking they will have 'made it' once they get a slip of paper certifying them as 'master of the universe'.

Strive for Competence

Do not go after experience or certification as your primary goal.  They will come as a result of your journey towards competence.  

If you make experience, certification or degrees your primary goals, you run the risk of gaining those primary goals without acheiving a true level of competence for yourself.  These window dressings and indications of possible competence should only come about as a result of your journey towards something substantive; real competence.

It doesn't matter if you had the right answer or not; what matters is that you understand why it is wrong or right.  Seek to understand why.

Practical Ways to Target Competence

Here are some ideas you can use immediately to strive for competence.  Add your own ideas in the comments!

• Go beyond the material - In classes, use the standard curriculum as a starting point for your personal inquiry, not the whole of your learning.  Do research projects on topics that interest you, on your own, to quench your curiosity.  The same goes for workshops, e-Learning courses, webinars, and other project management resources.  The fact you are reading this is a testament to your commitment! 
• Ask people to catch you screwing up - Actively poll your team, co-workers, stakeholders, everyone.  Ask probing questions like "I was wondering if you had any ideas for how I could do [whatever] better next time?"  The more specific your question, the better.  If you just ask "How was that?" people will nod their heads and say "fine" almost every time.
• Earning PDUs is not the goal - Look, if you go seek PDUs for the sake of PDUs, you're doing it wrong.  Someone seeking competence in project management has more PDUs than they know what to do with.  Remembering to document them is the hard part.

Share this with your network

I receive many passionate questions from the studio audience about which degree they should go after, how to prepare for a certification, and how to land a job as a project manager.

But many of them missed a step.

Is This For You?

Before diving in to the world of project management, it's important to take a step back and evaluate if this is even something you want to do.

A good starting point are my previous articles, the 10 Attributes I Look for in New Project Managers, and Run Away! (And Other Helpful Advice For A Career in Project Management).

Besides those attributes and passions I discussed in those articles, I tend to see one trait in common among people who end up being good at managing projects.

You know how they say if you love your work, it never feels like work?  That's not entirely true, but it is mostly true.

Loving to Bridge the Gap

This is the one thing that will carry you through tough times while managing projects.  But only if you really love it.

What I mean is a love for helping people understand each other.  I found very early in my career that I really enjoyed finding the little clues in a group conversation where I could tell people were not on the same page.  They were talking past each other, or at each other, many times without even realizing it.

I wasn't even particularly good at it in the beginning, and I continue to get better.

The second part of the process that I love it figuring out the right questions to ask, in the moment, to get people on the same page.  It's not a matter of demanding answers or chiding people; it's about asking the leading questions that will force clarity into the conversation.

For me, there's nothing better than the epiphany people get when they realize what the other person was really talking about, when all along they thought it was something different altogether.  Sometimes it's a look of astonishment, sometimes it's laughter, sometimes it's a groan.  Either way, suddenly the conversation 'clicks' into place and real progress starts being made.

And this is why project management is perfect for me.  In my role, I can find at least one situation like this every day.  Between my team members...stakeholders...managers and directors...customers.  Every communication channel contains the possibility of miscommunication, and therefore an opportunity for me to help resolve the disturbance.  This is just one of the things I love about project management.

Every day, I can do what I love.

Ask Yourself

Before you head down any career path, ask yourself honestly what it is that you love to do.  I don't mean as a job, but what are the little things you enjoy and would like to do more of?  What are the things you abhor and want to do less of?  Only after this analysis should you decide whether or not project management is for you. 

I feel strongly about this and so the first 2 (out of 5) modules of my PM Career Coaching course are dedicated to finding the answers to these questions for yourself.  I have a structured approach with worksheets, but you can just get out a sheet of paper and start writing down the things you enjoy and the things you don't enjoy.  These are activities and behaviors, not jobs.

You might be disuaded from going after a career in project management.  If so, great! 

The primary goal is to find the work you love.  If that is not project management, so be it. 

Go find out what it is you love.

Share this with your network