Posted by Kav Latiolais on June 23rd, 2009 (
1 comment)
We’re a community of project managers, but most of us are also people managers.
What is the difference between project management and people management? Are all people managers also project managers, and if so is there a role for a project manager that isn’t also a manager of people?
Does successfully managing a project inherently require somebody who either directly manages the people working on the project (or has the skills to be able to do so)? If not, are there situations where somebody can be an effective project manager while being an individual contributor?
Quite frequently the Project Manager is not in the management chain of those they coordinate. This does remove the ability for such Project Managers to resort to “because I say so”, but as most people managers will tell you that is absolutely the last way to get work done and often ineffective. An interesting question that arises from this is which skills are more important in such a project manager; the ability to manage without authority, or strong project management skills. Pawel, one of our contributors asked this very question on his blog at http://blog.brodzinski.com/2009/04/which-project-manager-would-you-hire.html
Managing without authority is a key project management skill. In fact if by “project manager that isn’t also a manager of people” you mean someone who lacks the soft skills needed to coordinate a team our panel of experts gives a firm no. As a Project Manager you must deliver results by convincing others to follow your vision. Don’t kid yourself that the power to fire someone or review them a few times a year gives you some magic key to getting the best out of them. As one of our contributors noted “A poor manager tells people what to do. A good manager helps people understand what needs to be done.”
A frequent pitfall for project managers in this position is insufficient buy in. If you are not in the management chain of those working on your project you absolutely need to ensure buy in from that chain. If a contributor’s manager is pressuring them to focus on other priorities while you are trying to get them to commit to your project you are putting them in a rather nasty bind and likely losing credibility. Given this, it’s also a best practice to regularly meet with people managers to ensure everyone is on the same page.
Tags: managing without authority, people management
Posted by Rodica on May 18th, 2009 (
Add a comment)
I’m getting ready to kick off work on a brand new product (yes, brand new! Not an incremental change to an existing product, but something the world has never seen.) We have a bunch of random feature ideas, but the marketing guys keep coming by and asking what our “value proposition”. I read around a bit online and it seems like a clear value proposition is probably useful for our product. But I don’t know how to go about starting to write one.
What tips and techniques have others picked up for building out a value proposition? I’ve already read Scott’s book on how to write a vision document, but I think the marketing folks are asking for something a bit different. Anyone have tips?
Suggestions:
Typically a product manager task – however, you can help by reading up on some product management literature can help phrase the value of your product.
Narrow it down. The best value propositions I’ve seen are literally a single sentence. It’s one thing that several constituencies can buy in on, on their own terms.
If no one would pay money for this, do not build it. The value proposition should explain why someone would want to purchase this and what the company stands to benefit.
Do your work ahead of time. What is the value it will bring to the company/customer? How much do you need invested in product design, development, maintenance? What’s in it for the company? If you answer these questions first, you can then dial in your elevator pitch.
Resources:
http://en.wikipedia.org/wiki/SWOT_analysis
Elevator Pitch: From Geoferry Moore’s Crossing the Chasm
Product Box Exercise by Jim Highsmith. See http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html
Puget Sound region to look into UW Extension’s Software Product Management certificate Program http://www.extension.washington.edu/ext/certificates/sod/sod_gen.asp
Steve Tockey’s book: Return on Software: Maximizing the Return on Your Software Investment http://www.amazon.com/Return-Software-Maximizing-Your-Investment/dp/0321228758
Tags: value proposition
Posted by Kav Latiolais on May 7th, 2009 (
1 comment)
I’ve been asked to perform a post-mortem on a project that I wasn’t part of myself. One goal of the post-mortem is to give input to the project manager, project members and the organization as a whole on how to improve the way we run projects. Another goal is to give project participants a chance to influence how projects are run and make sure that they feel that they’ve been heard.
From the outside it looks to me that the project was successful. It produced results that seem to lie reasonably well in line with expectations. However I’ve heard rumors that there are unresolved conflicts between project members and that everyone isn’t happy about how the project was run or about the end result.
My usual approach to project post-mortems is to gather everyone involved in a room and discuss what went well and what can be improved. However I’m afraid that everyone won’t participate in such a discussion or that conflicts will surface that I won’t be able to handle.
How should I approach this task to get the most out of it for everyone involved?
- Ensure full management buy in on addressing the issues raised. Without taking action on feedback a post mortem simply becomes a gripe session and will only hurt you and the team.
- Meet with key stakeholders to get background and history. As an outsider you need to get a feel for the lay of the land. Meeting with a few people to get the story of the project is the first step.
- Survey the broader team. This survey should tailored based on you earlier conversations. Those who wish to offer anonymous feed should be able to do so. The survey will also be useful in identifying those with whom you should follow up. Additionally this prevents the outspoken from dominating and driving the post-mortem process.
- Meet one on one with team members based on survey results or across the board. Don’t forget to include employees outside of the core disciplines. Build engineers and technical writers often have fantastic perspectives. Focus on collecting concerns that must be addressed and key lessons rather than complaints. One strategy for turning complaints into actionable feedback is to ask “What would it take to make you feel better about that?” or “What would success look like?” Don’t be afraid to find out what went right, sometimes holding onto success is harder than avoiding failure.
- Turn concerns and lessons into proposals. Depending on the size of the group you are working with you may want to perform smaller group sessions or do this as a single meeting. The goal of these sessions is to get feedback on findings and turn concerns and lessons into actionable items. Ensure everyone agrees with the rules of engagement before entering the room. Lay them out again before starting the meeting. Having a partner also helps during such sessions as one person can keep the discussion on track and under control while the other takes notes and observes interactions.
- Present your findings, commit to actions and dates. At this point your goal should be identifying time frames and owners for the actions developed during the previous sessions. Don’t forget however to celebrate successes. This project achieved great things, don’t be afraid to call those out. Your action plan should help carry these successes forward.
Recommended books covering this process: Norm Kerth’s Project Retrospectives and, for smaller teams, Agile Retrospectives by Esther Derby, Diana Larsen and Ken Schwaber
Tags: post mortem, retrospective
Posted by Shawn Murphy on April 27th, 2009 (
Add a comment)
Later this week I have the opportunity to give curriculum feedback to the computer science department at a major research institution in the United States. They are looking to update their curriculum based on feedback from industry. This is a rare opportunity that should be shared.
Given your experience, do computer science college graduates have the skills necessary to be effective and productive project managers, developers and testers?
If they don’t, what do you have to teach them in order for them to productive? How long does it take you to teach them those skills?
As you expect from a group of project managers, teaching “project management” was suggested.
A couple of key topics were raised:
- Teamwork. All programming everywhere involves teams. CS graduates are entirely unprepared for how to thrive on teams, build the relationships needed for teams, and to use the skills of collaboration to their advantage. In his last lecture Randy Pausch describes how he required his students to grade their project teammates on how easy they were to work with to generate a peer ranking at the end of the class. Scott conducted an interview with Steve McConnell on this topic for O’Reilly’s upcoming book Beautiful Teams.
- Internships. Internships were frequently brought up as the best way to teach the practical skills that college students need to have to be productive in industry. The only project with internships (especially if they are required) is that they require industry to provide enough internships for all CS students. In addition to internships, outside projects are a great way to continue refining the development and interpersonal skills that are taught in internships.
- Good communication and interpersonal skills. While this is related to teamwork, being able to clearly communicate your ideas and knowing how to work with other people to negotiate and collaborate on a design problem are critical skills in industry that aren’t taught in school. Considering how many engineering problems are sometimes personality problems between engineers it’s surprising why hard skills for conflict management and communication aren’t taught.
- There is no right answer, only trade-offs. Often new graduates approach the world thinking there is a single right answer to an engineering challenge – completely ignoring the business, finance or marketing requirements and strategy. In industry we routinely make trade-offs between schedule, costs, scope, and quality in addition to balancing the needs of every aspect of the business with the ‘cleanness’ of the code.
- Design. Specifically how to design systems that work well together and for the user. The following books could be used as the reading list for teaching that art of designing software: Sciences of the Artificial, The Design of Everyday Things, General Systems Thinking, The Mythical Man Month.
Tags: college, computer science, internship, teamwork
Posted by Shawn Murphy on March 17th, 2009 (
1 comment)
We’re having problems with our ISP - the list is temporarily on hold. We’ll update as soon as we have more info. Watch http://patoomba.com for progress. Sorry and thanks for your patience.
UPDATE: We’ve fixed our hosting problems by moving to a new host provider. Existing list members were sent an invitation to confirm their subscription to PMClinic. Please accept the invitation and join us on Monday for our next topic!
SECURITY NOTE: If your browser complains that the SSL certificate for the website that confirms your subscription points to lweb2.lynnwood.netriver.net instead of of www.patoomba.com it’s ok. We don’t have a SSL certificate for patoomba and lweb2.lynnwood.netriver.net is the server hosting the site and the mailing list.
Posted by Scott Berkun on March 8th, 2009 (
Add a comment)
Here’s this week’s situation:
A client of mine is faced with an interesting situation. He’s a PM/ team lead working in a small software vendor providing an SaaS platform - as such, the “project” is long-lived rather than something with a clear beginning and end. They’ve been trying out some Agile practices, with varying degrees of success. One of the thorns in his side is one of the team members, who is very productive, works upward of 10 hours a day purely of his own initiative, and who regularly checks in code that our PM deems below par.
Because of the long hours and high motivation he seems to have attained a “star” status of some sort within the company. Perhaps due to that (or so the PM hypothesizes) he has so far resisted most encouragements to change his coding style to align with the rest of the team. A few of them, for instance, have had good experiences with test-driven development, but their superstar won’t even try it.
I have my own ideas what my client might do, but I’d be interested in your thoughts. What would you do ? Besides the two-word obvious answer, I mean.
Despite warnings against, it the first response was our favorite two word rejoinder: fire him. But quickly debate began about whether not following coding rules, which can be arbitrary, was a sign of someone who needed to go.
Key points raised:
- Michael Jordan, and his work ethic was brought up, making the point that real super stars outwork their peers. If the star does all the little things, then the rest of the team has no excuse for not doing them too. That’s what a good leader or star should be doing - setting an example.
- Hours worked is a poor measure of value. The effect of people’s hours is what you want to measure, not how long it takes them to do things. Half of his hours might currently be spent on low priority things that are a waste of his energy.
- No programmer will follow rules s/he didn’t sign up for. Involve them in setting the rules and odds of them following go up. And any rule should have a process for it being reviewed or revoked. Some rules are grandfathered in and no one knows why they’re followed anymore.
- All critiques of code or process should come with a counter-offer. “This sucks” is not productive. But “there is a better way and here’s how it’s done” is. This behavior starts with leads and managers.
- Someone should be the official leader of code quality. It’s probably not the project manager. Whoever this is should lead the definition of coding practices, code reviews, test driven development, etc.
- Create social psychology effects for breaking rules. Most teams have a silly hat, or stuffed animal, the person who breaks the build has to wear. It works without requiring a big rule sheet or yelling at people.
One good suggestion for approach was to talk privately with this outline:
- Recognize star status. “I love your dedication for this project. Your productivity definitely sets the bar for the whole team”. Don’t lie, but make start with acknowledging something they do well.
- Explain what you want as a challenge. Present the metrics, and appeal to a higher purpose. Our competitive landscape will not allow us to slip up on this and we need to get better as a team if we are to succeed.Do you have some ideas on how to make this happen?” Questions invite conversations.
- Brainstorm some ideas and include your own. “I was thinking that standardizing the way we write code, using standard code styles,applying some basic principles such as clear variable naming”
- Clarify authority and his role. “If you have some idea on how to change something, please share it with me first.” You can’t get angry at someone doing something they didn’t know you didn’t want them to do.
- Set dates and goals and let him run with it. “Let’s revisit this in two weeks and see where we’re at.”
Tags: 1 on 1, facilitate, process, rockstar
Posted by Shawn Murphy on February 27th, 2009 (
Add a comment)
My new team appears to be playing fantasy schedule, which bears a substantial resemblance to fantasy football: at the beginning of the project everyone picked some numbers that appeared to come out of their hat. Now, they move the numbers around every couple weeks in an attempt to make up the amount they’re obviously falling behind due to the earlier numbers. Sometimes made up numbers are traded, which is supposed to be a good thing. We have lots and of charts and statistical analysis. For all that, I think we’re likely to wind up in the fantasy schedule playoffs as much if not more than we’re likely to actually ship something soon. How can I bring things back to the real world? These people aren’t unfamiliar with scheduling, but their estimating skills are horrible, and I don’t know enough about the system to make them drill down to a useful level of detail. And yes, I tried the baseball bat. Then I had to spend 5 minutes in the meeting box.
Project estimation is difficult because it requires the “the future to be better known than it is”. Our community of experts identified a couple of themes that will help bring your team back to reality:
- A schedule is a tool to help teams be productive
- Task estimation techniques and frameworks that have proven helpful
- Books and resources your team should read
Read the rest of this entry »
Tags: estimate, fantasy, reality, schedule
Posted by Shawn Murphy on February 15th, 2009 (
2 comments)
I’m the project manager for a high profile project that was recently shut down, primarily for budget/recession reasons. I’ve volunteered to do a postmortem, as despite the fact we have a scapegoat for why the project ended early, there’s still lots of significant things I Want in the record, so we can discuss, explore and improve on them next time around. Problem is I’ve never run a postmortem before. What basic advice, or even references, should I become familiar with?
A well run post mortem can be one of the most rewarding, morale-boosting activities for a team – especially if the post mortem feedback is carefully considered and addressed.
“First and the most important question: do anyone plan to do anything about a post mortem? If no, well, doing post mortem just for a sake of doing post mortem doesn’t make much sense.”
Our team of experts consistently raised the 3 critical questions that need to be asked during the post mortem meeting:
- What did we do that went well (that we should do again)?
- What did we not do well that needs to be improved?
- What did we not do well that we need to stop doing?
Read the rest of this entry »
Tags: facilitate, post mortem, retrospective
Posted by Shawn Murphy on February 7th, 2009 (
Add a comment)
Patoomba strives to be the best place on the internet for project managers to share the truth about what goes on at work. Our community is casual, comfortable, smart, and functions through debate, the exchange of ideas, storytelling, beer drinking, sharing lessons from failure, revealing secret tactics, sarcasm and friendly ridicule. We believe these are the ideal ways to learn from each other and get better at what we do.
Each week, we explore at least one topic (the weekly situation) in PMClinic – a moderated discussion on topics in Program Management. The moderator sends out the weekly discussion topic from a backlog of topics submitted by the community or the general public. Our esteemed body of project management experts playfully destroys everybody’s hope by dissecting the problem and offering helpful advice (or at least making fun of the moderator).
If you have a topic or situation that you’d like to discuss, please send that topic to askpmclinic@patoomba.com.
Learn more about who we are, how we work, and how to join our discussion.
Tags: Patoomba
