pmStudent

I am in the process of a paradigm change for a project team I was recently assigned to.

I have discovered (once again) that methodology matters, but perhaps not in the way you are thinking right now as you read this.

What I Don't Mean

No, I'm not saying that Scrum or CCPM or Waterfall are "the" best method of managing projects.  When people start talking about how one methodology is better than all the rest, their perspective is often clouded with ideology.

What I Mean Is...

The processes you use to manage projects does matter.  Mostly, the project environment, team(s), and stakeholders will lead you towards a way of managing projects that is a hybrid of the well-known models out there plus lots of organization-specific pieces that you won't find in any manefesto or "how-to" book on project management.

My Example

For my example, I am working on a large federal contract with a small team who is responsible for 2 of the 8 or so subsystems within one segment of the project.  The project as a whole, and the individual contractors are using traditional waterfall methods and EVM, with multiple releases of the subsystems (a.k.a progressive elaboration).

My team has had experience with Agile methods in the past, and they love working that way.  So do I.  So.....

We have collaborated on a hybrid approach that uses some of the aspects of Agile (Scrum in particular) that we can gain clear value from while throwing aside some of the other aspects that just won't work well in our environment.

For process, we will be doing 2-week sprints with the standard major releases, product backlog, and sprint backlog.  We did our first sprint planning session today which went awesome, and we'll do informal retrospectives too.  We will have daily tag-ups for 15 minutes each morning to ask and answer the following questions:

1. What did you do yesterday and how much is left on those tasks?
2. What will you do today?
3. What worries or obstacles can you see currently or on the horizon?

For tools, I started with a Scrum template from Petri Heiramo from Digia and modified it heavily to fit our unique needs.  I added resource-loading capabilities to the template and other key pieces of functionality, including a tab which translates the Scrum-ish progress updates into a format I can easily update our main project schedule with.

Not Throwing Out the Baby, But Some of the Bathwater Must Go

We are not doing the standard software development you might see with Scrum. 

We won't have discrete releases at the end of each sprint, so we've thrown that part of the Scrum methodology out.  Instead, each sprint gets us closer to a major release with clarity of planning and the ability to respond to the changes we enjoy on a daily basis.  Our subsystems are almost entirely database systems, but they support and integrate with all of the other subsystems and so many changes in those subsystems impact us directly.

Which is why I'm also throwing out the idea of a sprint baseline (sort of).

We've decided that after the initial sprint plan is finished for a given sprint, I'll save it as a baseline but then a working copy of the tool will be modified on the fly, daily.  We'll remove and add tasks, adjust estimates, whatever it takes to respond to the constant changes around us.  We'll get better at estimating as time goes on, anticipating potential changes and rework coming from outside the team, etc.

So Agilists will say we're not doing "real" Agile.  And Waterfall enthusiasts may glare at us.  So what?  I've ensured I can meet or exceed expectations for advanced and short-term planning, and excellent status reporting.

We've worked out a promising process that meets all our needs and my team and I are jazzed about.

And I couldn't be happier.

Image:  Cookie cutters by G & A Sattler via Flickr

What do you think?  Got a comment on what I'm doing, or a story of your own to share?

That's right.

Have you ever noticed how the best way to learn is to watch people who are really screwing it up? 

Call it the Tool Time Phenomenon.

I've been reminded recently that if you really want to destroy your chances of success, the best thing you can do is neglect communication.

Specifically in this case, if you want to make a mess of things be sure to rely on email communication with your team for simple one-sentence questions even though they are about 20 steps away from your desk. 

Whatever you do, don't have weekly one-on-ones with your team to discuss their concerns and feedback, talk about status of current work, and future work and milestones that are relevant to them as an individual.

Oh Oh!  Be sure to undervalue the importance of team tag-ups too, and when you do have team discussions, be sure to bog it down by making everyone sit through your gathering of status updates (because you didn't do that in a one-on-one).

When there are activities going on that are related to your team's work, be sure to not share it, even as an F.Y.I.  No, instead you should figure that if you can't think of how it impacts their work in some direct way, there's no reason for them to know anything about it.

What other lessons are waiting out there for all of us?  Have you witnessed a Tim "The Toolman" Taylor performing some educational magic on what not to do with regards to communication?  Do share!

-Josh

I have recently been tasked with taking over a project team.

When you are coming into a pre-existing team dynamic as an outsider, it's always tough.  If you are new to project management it can be a nightmare.  Let me share with you some of the things I am doing right away, and please offer your own best practices and questions in the comments.

One of the first things I did is made a list of initial items I need to know about:

• Who are the people on the project team?
• What are their roles?
• Who is my sponsor?
• Who are the key stakeholders?
• What are the relative levels of engagement and influence of the key stakeholders?
• Who are the key collaborators my team will work with?
• What is the current state of communication on the team? (meetings, status, etc)
• What is the scope and requirements of this work?
• What milestones are coming up on the schedule?
• What risks are we tracking, and are there any new ones keeping the team up at night?
• Do we have any current issues that need to be addressed?

In my environment, the System Engineering and Project Management is rather formal, so I had the benefit of being able to absorb material in Operations Concept documents, software design documents, and interface documents in order to get some basic knowledge of the technical context.

Over the next week I'll be meeting with the team members and implementing my standard process of structured, weekly one-on-ones and continuous feedback model.

So what do you think?  Did I ask all the right questions, or am I leaving something out?

Image by Kapungo via Flickr

Josh gives an example of how project team building can be done in a fun way, in a complex environment.

This is just one example.  How do YOU create fun activities for your project team? 

Share your examples in the comments.

Ty posted an interesting piece on leadership that I commented on, and am about to expound upon here.  He referred to successful project work being led, not managed.

I'm going to disagree, at least slightly on what may just amount to terminology.

Successful project-based work is led AND managed.

There is a false dichotomy between leadership and management that I often see. While it is true that you can be a leader without being a manager, and you can be a manager without being a leader, the highest state (for a project manager) to achieve is both simultaneously. As my former PM mentor and engineer Brian Bernhard used to say, it's the "genius of the AND".

A general, CEO, technical innovator, or scientist can get away with being a great leader and lousy manager if and only if they surround themselves with great managers. The general and CEO in that case rely on their vision and strategic capabilities, and the technical innovator and scientist rely on their ability to create movements through technical breakthroughs.

A team manager can get away with being a great manager and a lousy leader if the environment doesn't call for innovation or great leaps forward; change is infrequent and most of the activity is similar to the way it was the day before or last year. Here, you need a great manager who understands how to manage people effectively day-in and day-out.

For a project manager, you really need to aspire to having both qualities. With the change and constant need to generate and sustain momentum towards a common goal, you can't be successful for long without developing at least a minimum amount of both qualities.

 

Leadership is a sexy attribute that everyone wants to be associated with.  However, do not forget about the importance of effective management.  Frankly, I don't want to hire project managers who can not manage teams, stakeholders, and projects effectively.

To use a sports analogy, it's about blocking and tackling combined with inspiration and empowerment.  A good coach needs to be effective at both leadership and management, not one or the other.

We are project coaches.