I really like the use of “stories” in Scrum as a means to capture requirements, refine them, work them, and track them to completion and approval.  And I’ve played with trying to introduce that idea into my regular operational work … with limited success.

What’s a Story? The basic structure of the Scrum Story (requirement) is this:

(User Role) needs to do (this) so that he can accomplish (that).

Then one refines that with some detail, some deconstruction into smaller stories, if needed, and very importantly, testing criteria that further define exactly what (this) and allow for eventual testing and approval (acceptance).

Don’t we do that already? In the various ways we gather requirements in traditional waterfall projects, I think we often lack this complete albeit high-level statement of each requirement, and we often get lost and derailed on details without a clear vision of the use of or the payoff for that requirement. A good PM can manage that, but it’s a common weak point, I think.

So far, meh. So, in our loose PM practices in my team, I have tried a few times to introduce this Story mechanism. Strangely, it has not caught on easily. When I have seemingly convinced the team to use it, it quickly derails into a more technical requirements list instead of the real “story” feel that I hope for, and as a result, we lack some of the benefits of the story.

But I think it’s worth continuing to try. I still put my hand to it once in a while. I need to wait for a project when the story approach solves an obvious problem the team is having, then it will resonate better.

What do you do when you're handed a new project? How do you take a "project" that hasn't been managed and manage it successfully? 

Here's the story. I attended a conference call for a group that I've been helping off and on. The IS&T leader, the business leader, and a few staffers have been progressing along a billing configuration change to be made. I listened, being careful not to contribute too much and certainly not to offer any PM help. I have enough on my plate, and they have other PMs they can engage. But, alas, an hour after the call ended, they reached out to my boss and asked for my help. Now, I know that I should be flattered that they asked for me by name, but my real reaction is akin to fingernails on a blackboard. 

But, having overcome the cringing, I'm ready to engage and blow their socks off. But what to do first? How does one take on a project where they sort of thing they might need some help, but where they generally think that they can throw things over the wall and they just happen? 

I think all projects, large and small, come back to some basic principles. How far you develop those principles and what tools you choose to use are matters for the art of project managing and are impacted by the size of the project, its complexity, the organizational culture, and the preferences of you and your team.

What are the basics? Definition. Scope. Time Line. Those are the things that will give you early understanding and control, and that will help your sponsors and leaders gain confidence in your skills as a Project Manager. 

I. Definition.

Start with the most basic definition of the project. What have you been handed? 

* What are the goals of the project, stated and unstated?
* What does "done" look like? How will we know when we're successful? 
   * Who gets to say so? 
* Who are the key players? Who will be doing the work? Who can identify the work? 
* Who are the end users, the customers? Who's talking to them about this? Who should be? 
* Who's paying for it and how? What's their expectation from you? 

For a small project, you can get all that on the back of a napkin and start moving forward. Yes, really. You don't need fancy tools for everything. For other projects, you might need several lists of stakeholders, key contacts for each group, an understanding of each group's expectations, and a communication plan for each group. 

II. Scope & Resources.

Once you've got this basic definition, then you've got to go about defining the work. What is the work to be done and who's going to do it. If you're not the expert, you'll have identified the experts in the definition work. Now dig in with them and figure out all that has to be done. Track it somehow.

You can use a traditional Work Breakdown Structure (WBS), which is quickly conceptualized in a mind map. You can use a list of User Stories as is done in Agile projects.

However you capture it, make sure you understand what you're capturing. Can you put it in order (dependencies)? Can you assign it? Can you check it off when it's done? Whatever your format, this is your project scope. 

III. Time Lines (Schedule).

With definition and a scope on their way, you'll need to think time lines. Get it assigned out, scheduled, and start monitoring the work. You need to communicate to leadership in terms of time lines and percentage done. A good tool for this is the One Page Project Manager (OPPM). Simple, straightforward, complete, and adaptable. 

Those three things — definition, scope, schedule — are  It's lots of asking questions, taking notes, and organizing other people's knowledge quickly. But it can be done. And it can be fun. And it can be wildly successful and impressive. 

Certainly, there are tomes of refinements to this, but this is the basic. Start down this path with only this much knowledge, learning as you go, and you'll be on your way as a fairly decent project manager. 

#pm   #pmot   #wbs   #agile  

Embedded Link

Your WBS Coach « CottagePM.com
Work Breakdown Structures That Work — And How To Implement Them. I’ve written several times on the blog about the Work Breakdown Structure (WBS) as a core tool for all project managers. I practiced a …

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

I've blogged about the One Page Project Manager before. In my role, I don't do a lot of direct project management any longer, but I'm more apt to advise or manage project managers. I've learned to let each PM use the tools that they prefer. There is no right or wrong in tool selection as long as one is working effectively and getting things done. 

This week, I have the opportunity to help manage a quick, short project more directly. The small team and I ran through the basic requirements and discussed a high-level time line. We're going to be using some Agile principles in this project because there are still some unknowns, some skills that we don't have yet, and things that we'll need to learn and refine early on to gain the efficiencies necessary to complete the project on time. 

To help organize the high-level requirements and to facilitate roll-up communication about the project, I pulled out my One Page Project Manager (OPPM) template and plugged in the pieces that we needed. The Subject Matter Expert who'll really be running the work like the organization of it. OPPM quickly exposes major requirements against calendar and is effective for high-level planning and for status communication. 

Early next week, we'll try to figure out how we get all this onto the 5-week time line. It has us a little scared. We're letting that fear bake over the weekend hoping for creative solutions to emerge. Hey, don't laugh. They often to emerge like that on my team! But if not, we'll schedule it "brute force" style on Monday. 

Do you need an easy-to-use tool to summarize a project in language that non-PMs will understand? Check out the OPPM. I think you'll like it. 

#pm   #pmot   #oppm  

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

I've written before about how my project environment is a mix of operational and project management. I'm convinced that many of us, especially in the "Cottage PM" space, exist in those environments. We are operational managers, project managers, and we often both drive the project and produce work on the project. 

Much of project management literature not only ignores that fact but discourages it and discusses its drawbacks. Preferences notwithstanding, sometimes it just is what it is, eh?  

Getting Focus

Lately, we've been struggling with an environment where major projects move very slowly in the organization. As a result, we have many, many "irons in the fire," but the fire is burning pretty low. Then something will kick loose on one project, and we can move it forward. In the mean time, there are other projects that are more fully within our control, so we split our time working these projects while negotiating along the other projects. 

But it's not very efficient, and sometimes, we feel busy without ever being able to declare something is "done" and "delivered." 

How Agile practices may help

I've been pondering how to solve that in our organization, and I think that answer lies in borrowing some Agile practices and adapting them to our quasi-project / quasi-operational environment in order to get more of our work time bound and committed at predictable intervals. 

The Backlog

We already maintain a list of our Active "projects" and take status on that at weekly staff meetings. But the list is too long covering too many parts of the business. So we've already talked about rotating topics that we review, covering major areas in sequence over a pattern of 3 or 4 weekly meetings.

The next step is to get more of our work into committed, predictable releases.  I think that borrowing the Agile practices of "product backlog" and "sprint backlog" will be helpful here. 

Our product backlog is really our backlog of various projects that are requested and are at varying stages of negotiation and approval. These are not bound by a particular product, but span a variety of operations projects. 

Our sprint backlog would be similar — not bound by a single product or single project. Instead, I'm thinking that we get the team to break all their projects down into 2-week work chunks (or less), and to put target end dates on them all. Those with target end dates within the next two weeks become the committed work — the sprint backlog, if you will. 

"Sprints"

We can even use the time-bound sprint idea by simply dividing the year in to 2-week sprints. I like the idea of identifying them by week number. This week is week 43. If we start a new spring next week, then that's Sprint 44. The next spring 2 weeks later would be Spring 46. Projects on our backlog with due dates during weeks 44-45 comprise the Sprint Backlog for Sprint 44. Our staff meetings / review meetings would become meetings during which we commit to items for the next sprint and answer for items in the current/previous sprint. 

Remember our goal

The goal here isn't to be purely Agile because that's purely project focused, and we're not purely project. The goal here is to get our work "time bound," and to be able to commit to predictable, focused "releases." 

What do you think? 

#pm #pmot

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

OK – I just got email on this, and I’m excited. I haven’t even made an info page on the blog for it yet, but I feel like I’ve got to get it out there before I go to sleep tonight.

Cornelius Fichtner, who provides the very successful PM PrepCast to help project managers prepare for the PMP exam in a very ecnomical, flexible way — well, he has just announced the The Agile Prepcast!

The Agile Prepcast will be launching soon. It will retail for $129. You can sign up today to get a 20% discount coupon. You’ll get the coupon a couple of days before launch, and you’ll have locked in the discounted price of $104!

I’ll be spreading the word at my office. See, we are 4 PMP’s in my team, and we’re always looking at new methodologies and new ways to get PDUs (we especially like setting up formal mentoring and project review boards since we’re all coaches and teachers at heart). Anyway, we attended a Scrum training course earlier this year that was a bust. We did learn some good ideas and overview of Agile, and we’ve dabbled here and there, but we’re still not Agile. It’s been on our mind lately, and we almost attended another course offered from PMI that happened here locally last week. (It’s a discounted event for my team, the training vendor’s sincere expression of goodwill.) But alas, schedules didn’t work.

That’s why Cornelius’ Agile Prepcast looks so interesting. For a little more than $100, I get the same set of benefits I got with his PM PrepCast:

• 21 Contact Hour Certificate
• PMI-ACP sample questions
• 10 Key Concepts of Agile Development – Email Course
• Access to Discussion Forum

I hope that you’ll sign up so that you at least have the option of of saving 20% on the course. Even if all you want is 20 PDUs, these will be really high-value PDUs on an exciting, proven, and very effective approach to project management. Claim your 20% discount here!

Please join me in my study of Agile Prepcast!

CottagePM is a blog about PM methodologies and scaling to smaller project environments. I think that Agile as a methodology / framework / set of loose ideas provides the quick, direct, trackable, measurable action that small development teams can really wrap their minds around. I’m even going to be trying it with a group of Operational Project Managers (hey, that kind of thing exists in CottagePM!) to see if we can get more control over that list of projects that just can’t seem to get moving.. I’ll be writing soon about how those efforts go, and I invite you to come along with me, judge my ideas, watch as we succeed and fail — and learn.

But for now — sign up to get a great discount on what promises to be a great training product for the Agile Prepcast.

So you got your PMP! Congrats!

Now what?

I hope that your getting your PMP is just the beginning, and not the end, of expanding your professional knowledge. But what do you go after next? Here are some ideas.

1. Consider any "ah-ah" moments you had while studying for the PMP exam. Are there topics that really resonated with you? You may identify such topics either because they're intrinsically interesting to you, or because they are particularly relevant to a past or current project.

2. Consider whether you want "deeper" knowledge or "broader" knowledge about project management.

If you're after deeper knowledge, then you may consider some of the additional certifications from PMI, or additional certifications in PMBOK-style project management. Pursuing PDU's that are geared specifically to PMP's may be a great way to start. Some great reasources are Project Management e-Learning and the PDU Podcast (http://www.cottagepm.com/blog/pm-elearning and http://www.cottagepm.com/blog/pdu-podcast , respectively).

I think that you should also consider broader PM knowledge. Specifically, I think that you should consider doing some reading, watching some podcasts, or getting some training in Agile PM methods, or in other project methodologies, such as PRINCE2. There are other flavors of PM out there.

Why would I suggest that? Because I think that one of the first challenges of the Project Manager is to determine which project approach makes the most sense for the project at hand. All projects are not suited to Waterfall (PMBOK) project management. And all projects are not suited to Agile project management. No methodology is a panacea or guarantees project success. But the first decision that you'll take that influences your project's success is the selection of the methodology that you'll use.

I still firmly believe that if you don't know where to start in PM, getting a PMP or related certification makes great sense. I think that it sets a solid foundation for PM knowledge that lets you then explore the next conversations and knowledge that will influence your project success. Indispensable as I believe it is, it is not the end-all, be-all of PM. Get your PMP, then branch out and get some other PM methodology exposure.

#pm #agile #pmot

Embedded Link

PM e-Learning « CottagePM.com
Question: How can I learn more about Project Management? So, you're interested in learning more about Project Management (PM). Awesome! But now you're wondering where to go next, right? Here a…

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

OK, for both Scrum and Waterfall project management advocates, that title may sound heretical. But only if you're concerned with form more than function.

One can easily leverage good practices from alternate methodologies and frameworks into your primary project approach. A good example is User Stories.

In Scrum and other agile approaches, User Stories are the primary (only?) means by which product requirements are expressed. The basic formula is:

"As a <role>, I want to do <this> so that I can do <that>."

This gives great insight in the reason for each feature and function of the product. It provides great planning guidance. In Scrum, stories may start out very high level, but they are eventually split and decomposed into "Sprint-sized" stories, and possibly even smaller.

In Waterfall project management, these high-level stories can be leveraged to help identify requirements. It can be a challenge for a project manager to identify all the requirements for a project. One invariably forgets a whole branch of thought. Stories can help steer that creative thinking to identify requirements.

An important element in managing requirements is traceability. In waterfall project management, the Work Breakdown Structure (WBS) items are numbered in some fashion, and these numbers should be carried forward to all artifacts that involve delivery of that work package: cost codes, tasks, etc.

(For an excellent discussion on WBS and traceability, including some examples, grab a copy of Josh Nankivel's WBS Coach package; see link below.)

Stories could serve as the highest level of traceability. Imagine having all WBS items, all requirements, all cost codes, all tasks ultimately traceable back to a user story that explains why that element is valuable to the product!

Give it a try!

#pm #scrum #waterfall #wbs

Embedded Link

Your WBS Coach « CottagePM.com
I've written several times on the blog about the Work Breakdown Structure (WBS) as a core tool for all project managers. I practiced a long time as a PM without using the WBS. I can see a big diff…

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

I recently attended a Certified ScrumMaster training class. I'm now Certified ScrumMaster (CSM). That should mean more than it apparently does.

The course was a severe disappointment. An arrogant instructor using a disorganized teaching method supported by weak course materials.

Still, I'm impressed with Scrum as a framework. (Woe unto him who mistakenly calls it a methodology. #sigh ) My team and I were interested in Scrum because we tend to do things in a team-oriented, collaborative, flexible, learn-as-you-go way. It works for us. Our goal in pursuing Scrum is less about adoption the whole practice, but rather, to gain some insights and a few tools to help us do better what we naturally do well.

In that regard, Scrum is already benefitting us. Here are the aspects that really resonate with us:

* Tracking requirements in user stories.
* Tracking stories in a dynamic Product Backlog.
* Better release management than we were doing.

We like and use a Sprint-like idea, but we are quasi-project, quasi-operational most of the time. We're running several "projects" simultaneously on several tools. Unless it's a big new thing, dedicating just to one item for a month doesn't resonate well with us at all.

It's also a little amusing. Scrum types are rather attached to pursuing "pure Scrum," thumbing their noses at anything that strays from a purist approach. Unless, of course, they approve of the variation. Had its founders been so purist, Scrum might never have been developed through iterative experience. Just sayin'.

I'll write more about our attempts at Scrum. And our heretical variations.

#blogpost #Scrum #Agile #pm #pmot

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.

OK, that’s a little misleading. There really wasn’t a collision. But there could of been. But a seasoned IT executive nimbly navigated the team through recognizing the differences in model between 2 teams that now had to work together, and they’re finding their way through it.

One Business Unit has had a good track record running proper Agile projects. They’ve brought several projects to market using it. They trust it, they’re successful, and they know what they’re talking about.

The IT organization is traditionally Waterfall. They count on Charter’s, extensive architectural designs, complete planning and resourcing up front, etc.

Now the BU and IT have to come together to launch a new customer portal. The BU owns the project and key project resources. IT will be providing API’s and server support, etc.

But when we started talking project process, talk about confusing! The IT exec openly states that he really doesn’t understand Agile, and that all the Agile projects that he’s seen before were dismal failures (because they weren’t really run Agile; they were run sloppily). But he knows the track record of the BU and is open to supporting it. But he wisely recognized that the IT team wouldn’t know how to interact on an Agile project, so he helped guide the combined team through some high-level understanding of the approach challenges. We’ll follow with a kickoff that includes some specific approach instruction for the waterfallers now having to be agile.

A lot of organizations probably face similar things, but may not all navigate it well. Project leaders need to be conscious of selecting the right approach for the project (to wit, Waterfall or Agile or something else) and to bring along the project team’s understanding of the project approach so that they can executive it well.

Projects really don’t just happen. And a variety of approaches can be used on any given project successfully — but not all at one time! The project team has to settle on an approach and then drive that approach successfully.

I started writing this blog to explore the challenges I had scaling PM methodologies down to the scale of projects I typically ran and worked on. Every training or book that I studied on Project Management, including perhaps most of all the PMBOK itself, included processes, perspective, methods, and tools scaled for a trip to the moon and back. All I wanted to do was organize us passing the quality management certification again this year. And that scaling was challenging — is challenging.

I had a conversation today that made me realize that we also can struggle in our project organizations with scaling up. One of our sites has been running successful projects for years. It’s not a tiny or a huge site. The projects have been continuous improvement kinds of projects. They’ve got the scale just right for their work, now, and can go about things rather relaxed because everyone knows the players, knows the technical environment, and knows the compromises and accomplishments of past projects.

But now that team is part of a larger organization as a result of a merger. And now they have to accommodate new risks and complexity: larger projects, implementation projects instead of continuous improvement projects, new players, new organizational rules, new systems, new sites, new business realities.

This project team now has to recognize that it has to gear up again — or scale up again — to handle these larger, riskier projects that tackle the unknown. And that can be awkward. You can be a really good PM, but if you’d not had to have a roles and responsibilities discussion in 5 years, it might be awkward. Or even a project approach conversation: waterfall or scrum. Do you even know what hybrid methodology you settled into (successfully!) in the last few years? Can you adjust it if you don’t really know what “it” is?

It’s not a recipe for failure, no. But it could be if we don’t adjust.