To Call a Spade a Spade
Categories:
Scope Management
Categories: Scope Management
| I had a conversation today that reminded me about a mistake I see project managers make from time to time. When creating a Work Breakdown Structure and the subsequent Basis of Estimates, some will use documentation as the key deliverables. The logic goes something like this: We don't have anything tangible to deliver except these documents, so hey, let's take all this other work, find which document it most closely relates to, and use that to hang our hat on. This creates a lot of problems. First, it's not accurate. You didn't take 600 hours to create that document. Rolling up your work this way gives the illusion that by axing that one document from the scope, it will save that much time and effort. Wrong! Most documents, especially in a project with a heavy IT focus, are created only as the 'documentation' of a lot of other time and effort. In my area, designing and creating build scripts, ERDs, data models, etc. might result in being ABLE to produce a good DBDD (Database Design Document) but all those pieces of scope are separate deliverables in and of themselves. Second, it confuses your scope and the ability to create and track meaningful tasks for your team. Creating the document is not the primary goal; the primary goal is delivering all the work (code, designs, etc.) that eventually gets documented in a formal fashion. Thanks for reading my rant. A penny for your thoughts? |
New Project Managers: It's OK to Make Mistakes!
Categories:
Lessons Learned
Categories: Lessons Learned
| Everyone makes mistakes. Even if you are supposed to know a lot about a topic, it can be nearly inevitable that you will make a mistake or forget something you should have known.
-Josh |
Taking Over a Train Wreck
Categories:
Project Leadership
Categories: Project Leadership
| The team is awesome. They are smart, motivated, and want to do a great job. The last project manager? FAIL You're the new project manager, and you're speaking to variances on a baseline that forgot what reality was last fall. The WBS is structured to look nice, not to model the actual breakdown of work on the project. The schedule was made to be convenient for upper management, not to be a representation of the actual work that has to get done. Arrrrgh! How To CopeThe first thing is to get a handle on your scope. Without that, trying to manipulate a schedule is futile. The WBS (Work Breakdown Structure) to the rescue! Scared at what the reaction of the developers will be, you decide to sit down with them and create a WBS together anyway. Oddly enough, a little while later you have a draft that looks pretty darn good, actually. The team is already getting used to the idea that they can glance at this diagram to get a clear sense of what they need to deliver. Now that your structure for work breakdown is solid, you can start breaking down the deliverables into the tasks it will take to produce them. I do this in a BOE (Basis of Estimate).1 Then, you can start to produce a schedule (at least a working schedule) that really tries to model reality. Depending on the project environment you are in, you may be able to re-baseline the project right away or you may have to wait. You may have to speak to variances for a long time however.
What advice do you have for others in this situation? Have you been in this situation yourself? -Josh 1 WBS Coach, WBS and BOE integration on page 50 of the textbook |
Project Management Supertaskers
Categories:
Multitasking
Categories: Multitasking
Methodology Matters, But I Don't Fit Your Mold
Categories:
Methodology
Categories: Methodology
| 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 MeanNo, 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
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:
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 GoWe 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? |
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).
