Agile and the PMO Working Together By Curt Finch It often seems that a lean, agile development environment will always be at odds with the structure and constraints of the PMO. Yet it does not have to be this way. The agile PMO can bridge the gap between these two very important groups and help organizations to [...]

 

Journey - Courtesy Flickr

The Journey

This week I shared with you some quotes that have helped to inspire me through some tumultuous times.  I find they make me feel energized and able to inspire others and pave the forward when ‘things go wrong’.  And, things almost always go wrong in projects – don’t they?  So, in addition to our standard toolset of project management, I encourage you to seek inspiration, be inspired, and inspire others to do their very best and excel at whatever projects you are leading.

I am listing the quotes that have inspired me and were shared in the blogs during the week:

The difference between what we do and what we are capable of doing would suffice to solve most of the world’s problems. Mahatma Gandhi.

“I learned long ago, never to wrestle with a pig, you get dirty; and besides, the pig likes it”. George Barnard Shaw.

“I am always doing things I can’t do, that’s how I get to do them.” Pablo Picasso 

Hell, there are no rules here – we’re trying to accomplish something.  Thomas Edison.

Hope they gave you all some food for thought… and helped your journey this week.  Enjoy!

I would love to hear some of the ways you inspire yourself and your teams to reach higher…. Please share your thoughts.

I recently saw an email from a project sponsor that simply replied "SCOPE CREEP!" in response to the BA's concerns about whether the report being made as part of the project was going to adequately cover the business needs of the client. The BA had suggested a few additional requirements, like formatting and additional fields to include in the report. This was after the charter was written, but before the user requirements had been captured. I was flummoxed by the response.
How exactly is this scope creep? It seemed to me the scope of the project was "create a report for the client" along with some basic information about what the report would contain. In our organization's process, the charter is usually fairly high level, and is followed by a requirements analysis from a BA who comes up with the specific details for what the product should do. In my mind, the BA was simply fleshing out the requirements. If the BA had suggested a second or third report, sure, I'd (reluctantly) call that "scope creep." 
And furthermore, even if the requirements deviated a little from the original scope, what's the point of making a report that's not going to be useful for the client? Should the original scope be strictly stuck to come hell or high water, even if it results in a shoddy product? Is a project one that just stuck to scope? No!
"Scope Creep" has to be one of the most used and abused project management-related terms out there, and sometimes I want to find the person who created the term and shake them. To be sure, many projects fail because the scope got out of control. But I'd argue that the real reason those projects fail was that the original scope was never clearly defined in the first place. It's easy for the scope to change and a project to be delayed if there was no clearly defined scope to begin with. 
The PMBOK never intended scope to be something that was set in stone. It just states that it should be defined at the beginning of a project, and any changes should be reviewed, and approved or rejected based on whether they're deemed worth it to the project. The whole point is to look at changes critically and make smart decisions about them. And yet, scope seems to be one of those things that some PMPs and "armchair" PMs  seem to cling to as the most important part of project management.
At a PM class I took last year, the instructor asked the class what they should so, as PMs, if someone asks for a change to the project. I was surprised that many of the answers were along the lines of "explain that the change does not fit within the project's scope and that we cannot proceed with it." I wanted to tear my hair out. Being the "scope police" is not what being a Project Manager is about. To be sure, we have to be careful about the scope of a project, but change is not always a bad thing, and sometimes, if dealt with effectively, it can be one of the most important elements of a successful project.
So, I'm hereby proposing we retire the term "scope creep". It's too easy to cling to as a buzzword, and distorts the role that scope should play in a project. Any suggestions for a replacement?

I spoke again this year Carnegie Mellon University on the topic of project management in the software development world.

Not matter what method you use to develop the software needed by the project, for success these principles must be in place

Immutable Principles Of Project Management (V7 Final Cmu)View more documents from Glen Alleman.

How to Prepare for a Project Sponsor Meeting By Zenkara Sponsors are critical to almost all projects. They’re the people who get budgets approved, they’re the ones who provide the energy and impetus for getting the business ready for the project. Yet Project Managers often seem to treat them like they’re a pain in the backside and are [...]

Teri, a project manager from Jeffersonville, USA, was the first name out of the hat for the So What? giveaway.

Congratulations, Teri!  Your book is in the post.

Related posts:

1. Giveaway winner! Congratulations to Norma from Northumberland who’s name was first out of the hat for the copy of Rita Mulchay’s book PM Crash Course. Norma, your...
2. Giveaway winner: The Lazy Project Manager Congratulations to Lissa, from Eugene, Oregon, who won a signed copy of Peter Taylor’s book The Lazy Project Manager. Lissa, your book is on its...
3. Giveaway winner And the first name out of the hat was Tony from Essex, UK. Congratulations:  a copy of Sharm Manwani’s book IT-Enabled Business Change is on...

Managing Project Scope (#30 in the Hut Introduction to Project Management) By JISC infoNet In any project there are likely to be changes to the original plan during the course of the project. The changes may arise due to: The business case altering The need to find a way round a problem Identifying a better way to meet your objectives The [...]

This a very early draft of the introduction to Tags: Living In A Virtual World. I use this blog as a notebook for drafts, so you can provide me with feedback in an early stage. Comments are, as always, appreciated.

If you are a Project Manager that operates for a short period of time in a foreign organization, with a team you don’t know, in a domain you would not know how to spell, I would say you have some challenges.

Think about this Project Manager as a person in a huge network of interacting people. The PM can interact only with a few of them (his team, the stakeholders). The stakeholders interact also with others. People the PM knows, but more likely with people invisible to the Project Manager.

Because of the size of the network, because of limited visibility on the network, because of the complexity of the network, the PM is getting partial information, always.

For the same reasons the PM has only partial influence. He cannot interact with “everyone”. He has no “power” over everyone.

How do you get your job done?

The same problems arise when you operate on the internet. Lots of people you don’t know, huge amount of partial information. By looking at how this works in the virtual space, we get insights that can guide us in our projects.

Well, on the Net it’s all about Tags. And the things people think they represent.

Tags. Yes, Tags!

People can catalog almost everything on the Internet. You can add words to photos on Flickr that describe the picture. At Amazon, users can put labels on the products, labels they associate with the object. It’s called “tagging”.

Users from the bookmarking site Delicious add tags to the webpages they find interesting. If they put “project management” and “best article ever” to one of my webpages I’ll be delighted. If their tag reads “this sucks”, well, that sucks.

Image by dominiekth.

Tags are the little labels we put on everything on the web. There is no overall top down structure. Everybody can add tags. The tags can be any word or couple of words. Whatever your association is, it’s your tag.

A collection of tags describes a picture, book, products or blogger in a short and effective way. It doesn’t matter if it’s true or false. It’s about the perception of community.

After three years creating The Project Shrink, blog, podcast and persona, that’s how I view living online: a struggle with tags.

On Twitter I exchange short messages with other Project Managers. We have a secret handshake. Every message contains the letters PMOT, which stands for Project Managers On Twitter. By using these letters, you label yourself as a PM. And a cool one. One that is On Twitter.

The blog Project Shrink started out about “Project Management”. But I experienced that under that label humans don’t play a role. (At least, that’s what I’m told.) In “general management”: yes. In “human resourcing”: yes.

So I adopted “Project Leadership”. Now that is a lovely area in which you can throw any human topic you can imagine. The drawback is, nobody really knows what it is exactly. It may be a safe tag, but it’s not an effective one.

If you use a tag, you want it to be clear. You use a word, a word that means something to you. Agile approaches are getting more and more in fashion. Therefor more and more approaches are getting the label “agile”. To piggyback on the success.

Brian Marick believed Agile is being dumbed down. So he created Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism. Just to be sure no one would take that name and create it into something else. I am pretty sure that this tag wasn’t taken already.

Tags, or labels, are the social currency in the virtual world.

It’s the stuff we want to collect, get rid off or give online. This is not typical for online interactions. Labeling is a concept from sociology. According to Wikipedia “… is (sociology) the study of the social lives of humans, groups, and societies, sometimes defined as the study of social interactions.”

Online. Offline. Society. Project. Doesn’t matter. The kicker in the virtual space is, you actually use real tags. We see them. We use them as keywords in our filters. We use them in our one sentence pitch on LinkedIn. But still. Always the same principles. It’s about group affiliation and identity.

During your life you are a member of a lot of social groups, by default, by choice or by force. I am a Dutch white male, member of a no-child double income household, Project Manager, author and web aficionado, to name just a few of my own treats. The Dutch white male is something that I am by birth, by default. All other affiliations are more or less done by choice.

The group memberships determine how we see ourselves in the whole of society, it determines our identity. Actually, we have more than one identity. We can choose, we can switch depending on the situation. I like to see myself as a blogger and writer. Within the professional world I emphasize the software project manager affiliation. You have been dealt a lot of memberships, you can emphasize or down play each affiliation to create your identity.

As an identity is how we see ourselves within the ultimate large group of humans, it not something that can be seen on an individual level. It is a group thing. Without groups, the whole concept of identity wouldn’t make sense. We are shaping identities by combining three mechanisms: categorization, identification and comparison [Wikipedia]. Although broadminded people like to think they do not put everyone in boxes, everyone does.

We always put people in categories, we label them. This is done by looking for signs that we associate with a certain group. These signs are the mentioned use of icons, rituals or speak. To be able to associate yourself with a group, we first have to divide society into groups. Identification is the part where you affiliate yourself with a group.

The affiliation is done by taken on the social groups norms and other aspects which are used by humans to label an individual to a category. With the identification you label yourself to the group. To be able to do this, you take on the marks that cause the label. Comparison is looking for differences between groups. With the group affiliation you create your identity, your place in society. For this to work you are also indicating where you are not standing. It is always a comparison between groups.

A Short Writing Project: Tags.

It has been three years already since I launched The Project Shrink. I wanted to see if basic sociology could help me understand problems in projects. As DeMarco and Lister put it in their classic “Peopleware”: “The major problems of our work are not as much technological as sociological in nature.” So, it only makes sense to look at the social sciences.

Writing, discussing, interviewing and being active online provided me with some great experiences. The information and knowledge I acquired from running The Project Shrink form the basis of a small book I am working on: Tags (working title).

The information is applicable to offline situations. The information is incredible relevant for running virtual projects.

The table of contents:

1. Augmented Conversations
2. Trusting People You Don’t Know
3. What’s Your Beef?
4. Living In Networks: If You Build It, They Will Come
5. Transparency: Turning History Into Tags
6. What Happens If You Only See A Part Of Your Network?
7. Do Introverts Rule The Tag Game?
8. Why Your Company Should Help You Tag

Other people who liked this article liked these too

• Starting A Discussion About Team Diversity
• Went To London And Created Lenses
• Get The Virtual, Networked Organization

Subscribe with iTunes to "The Project Shrink" video podcast.

Tags: Sociology In A Virtual World

As a business analyst, I spend a lot of time focusing on gathering good requirements.  Once I have a high level set of requirements, I work to refine the requirements to the point where the developers will have enough information for design and implementation of the application.  Everyone has a method for achieving this requirements definition process but I would hope at the end they have a fairly robust set of requirements from which to work.

This is where I find myself at a loss when working in an Agile environment.  I know that only the user stories that are being worked in the current sprint are expanded.  These user stories encompass a subset of requirements for the project.  But at what point do those of you doing Agile find the simple 3x5 cards become unwieldy?  At what size project do you start to say "Maybe we need something to keep track of these user stories"?  And more importantly, where do you turn when you reach that point?

I have argued in the past that there are a lot of evidence-based disadvantages to working in an open office, as there are many more interruptions, distractions, and other stressors --- and of course less privacy.  And there are quite a few studies that show when people move from closed to open office designs, they don't like it all and their productivity sometimes drops.  I had an experience a few weeks back, however, that has me questioning the limits of this research -- and believing that if an organization has the right norms, leadership, and especially collective trust  (and have the right people and right skills to truly do cooperative work), that open offices can be a splendid thing. 

This all struck me a few weeks back when I went to visit  David Kelley at IDEO to chat about some ideas we were hatching for the Stanford d.school (which David, a Stanford professor, co-founded along with IDEO... David was the strongest driving force behind both ventures).  I had the usual delightful conversation with IDEO's receptionist (Joanie was working that afternoon) and went upstairs to what is best described as IDEO's "management floor," where IDEO's CFO, head of marketing, Chairman (David Kelley), General Manager (Tom Kelley), and CEO (Tim Brown) all work.  As I turned the corner to the main floor, sitting right where the receptionist on the floor would sit (if they had one, they don't) was none other than CEO Tim Brown.  I frankly took a double-take, as (in many organizations) he was sitting in just the place that would be reserved for an assistant, and frankly, would be seen as one of the lowest status places to sit because of the constant interruptions and because there was no gatekeeper to keep colleagues and random visitors like me from walking-up and talking to him.  I assumed this was a mistake or something, but became more puzzled when I realized that there was some stray group (including Chris Flink, head of  IDEO's New York office) in what I thought was Tim's office.  After I met with David (who was charming and fun as always), I saw that Tim was still there, and I asked him why he wasn't in his office. He said it wasn't his office any longer and that he had moved to what I would call the "receptionist's position," which made him -- as he later explained it -- "the most public person on the floor."

I called him a week or so later to ask more about this approach. He told me that most of IDEO's senior people had moved out of their offices and now when there was a need for more private conversations, there were a lot of small conference available (i.e., their old offices) that everyone could use.  He then explained that after working for IDEO for many years -- including as head of their London and San Francisco offices -- after he became CEO five or six years ago and was given his own office (albeit a pretty small one with glass that limited his privacy) he found it "vaguely embarrassing and frustrating to be in an office." After awhile, he and others moved to a different approach, where they were out in the open and there was more casual and exchange and fewer barriers.  I also asked Tim what happens when visits IDEO's other offices -- at places like London, Chicago, New York, Shanghai, and San Francisco. He said that -- although he spends time in conference rooms in meetings with IDEO people and clients (especially when confidential matters are discussed), he takes a desk in the middle of the action because "When I am there to visit and get to know the people and how they work, I can't learn much sitting in a private office."  

We also had a conversation about what he does when he needs a quite place to work, after all, he did write a great book last year called Change By Design.  He said that he has plenty of quiet time to think, especially when he travels, and that to write a book, well that was something that he did at home on nights and weekends!

To me, the upshot of all this is NOT everyone should move to an open office and every CEO should be in the middle of the social swarm like Tim.   Rather, the lesson is that what Tim and other senior people at IDEO do works when you have the right kind of culture and leadership, when the work requires interdependence and knowledge sharing, and people have developed the right skills and routines to work effectively when they are out in the open and on display to everyone else.  I think it is especially important to develop strong norms around courtesy, about how loud to talk, when to avoid interrupting others, and so on, and to make it safe for anyone in the setting to gently remind others when they are violating such norms.  I have noticed, for example, that it took some years to develop these kinds of norms at the Stanford d.school (the one "open place" that I work at a fair amount), and we are now -- on the whole -- quite considerate and respectful. The great thing about IDEO, of course, is that they have the kind of culture and skilled people who can make openness work.

P.S. In fact, if you are interested in Tim's perspective on the kind of people they strive to hire and develop, check out this recent interview that Morten Hansen (of Collaboration fame) did with Tim Brown on "T-Shaped People."

In my previous post, I talked about work commitments. Sometimes success in... Dmitri Ivanenko, PMP

 

Sometimes, you have to break the rules to get things done!

As we go through our lives we are subjected to numerous rules – as kids, as students, as workers and as adults living our everyday lives.  As program managers and leaders, part of our responsibilities is to lay down some rules by which to guide projects, by which teams work together and by which products are built, tested and released.  However, let’s not forget that the reason we have rules is to get us to a destination.   There is a favorite quote of mine which I invoke to remind myself of this principle:

Hell, there are no rules here – we’re trying to accomplish something.  Thomas Edison.

The program manager needs to know when to go by the books and follow the TL9000 (or your favorite development) process and when to let loose and have the team go off and run as fast they can.  I once worked with a program manager (let’s call him Joe) who could not tell the difference.  He was a ‘by the rules book’ type of leader – and that actually got in the way of us getting our jobs done.   We ended up getting to our destination despite Joe.  Here is the story.

Joe was responsible for leading a project on which I was one of the engineering managers.  We started out with a reasonable plan, and had regular program meetings, with status, minutes and action items that Joe would track.  Along the way, two things happened.  Our management wanted us to adopt a new development process.  And, at about the same time, we also had the inevitable ‘technical bump’ in the road that required our attention.  The new process rule required a detailed unit testing plan be documented, and signed off at completion prior to handing off to the QA team.  Joe was focused on tracking this new process requirement and getting the test plan documented.  The engineering team was very concerned about the bump.  Without addressing the bump, there would be no substantial development or unit testing to speak of.  However, Joe had it in our project schedule that the unit test plans would be done by a specific date and tracked that religiously at each meeting.  Joe also had very little domain knowledge and despite the team’s efforts to educate him on the criticality of addressing the problem asap, he continued to focus on the dates and the schedule.  Joe was following his rules book – the established project plan.  The engineering team decided to take matters into its own hands, and we held shadow program meetings without Joe to address the bump and quickly fix the key technical issues that were hampering our progress.  Joe’s rules were getting in the way of work being done.  When the crisis was over, I gave Joe some feedback that he needed to be able to adjust his plans when bumps came along, and bend the rules to meet our most critical goals.  To do that, he needed to learn more about the domain and understand the business of what he was program managing.  However, I hear he still manages the same way. Sigh!

Focusing on the rules and mechanics of program management helps keep things going.  But a good program manager needs to have at least a basic understanding of the domain and be prepared to apply rules or break the rules in order to get things done.  At the end of the day, the customer will not pay if we don’t have a good product, but followed all the rules!

The history of our future is filled with...

• moon bases
• jet packs
• 200 mph cars 

but has no...

• cell phones,
• Internet,
• and no laptop computers

Over the long haul, dramatic things happen to change the equation.

Sunil Paul, quoted in The Atlantic, “Better Luck This Time,” July/August 2009.

Via Wayne Abba's PMI Baltimore Chapter address, September 17, 2009. A former senior contract performance management analyst in the Office of the Secretary of Defense from 1982-99.

Forecasting the impact of the latest gadget, process, or method is very sporty business.

Ten Things to Look For When Reviewing a Project Plan By Dave Paradi When you are given a project plan to review, here are ten things you should look for to determine the quality level of the plan. Calendar Setup If you are looking at a plan, check to see when the next statutory holiday will be and see [...]

In his book Hidden Order: How Adaptation Builds Complexity computer scientist and psychologist John Holland describes a generic pattern for rulemaking in complex adaptive systems (like businesses and software projects).

Performance System
The first part of the pattern is what Holland calls a performance system. It consists of a potentially large number of stimulus-response rules, where the rules are meant to act upon messages received from the environment (or from other rules). The result of applying those rules is that a number of new messages are emitted, either to follow-up rules, or to the external environment.

Being a software developer my mind is filled with plenty of rules for building software. The input that I receive from the environment consists of the things my colleagues are doing (or the things they are only saying they’re doing), the code that I am working on myself, the requirements from the customer, the features and restrictions of the development environment, etc. The many messages from the environment are evaluated, in parallel, using hundreds if not thousands of rules in my mind, both consciously and unconsciously, which results in one or more new actions, like code to be written, changes to existing code, conversations with my colleagues, or discussions with the customer.

I know, this all sounds pretty obvious. But the key concept here is that the performance system consists of many potentially conflicting rules, where different rules are triggered under different circumstances, given different messages from the environment. It is as if the performance system is an ecosystem of rules, where rules are both competing and collaborating with each other, and the “fittest” rules are the ones contributing most effectively to the whole complex adaptive system.

Credit Assignment
The second part of the pattern is called credit assignment. Rules that appear to lead to improved performance of the entire system are credited, which increases their strength within the performance system. Rules that were triggered and subsequently failed to deliver beneficial effects, or even appeared to hurt the total system, will see their strength reduced. The strength of each rule determines the chance of being triggered the next time, for similar input messages.

Credit assignment assures that experience is built up in the system, by strengthening some rules and weakening others. The rules together form an internal model of what the world outside looks like and how the system needs to respond to it. And when the environment changes, strong rules will start failing and weak ones could succeed more often than before. This enables the performance system to adapt to new situations, and to continuously correct and tune its internal model.

Rule Discovery
The last part of the pattern deals with rule discovery: where do the agents in a complex system (or software developers in a project) get their rules from? Holland describes how new rules can be constructed from existing rules by recombination of building blocks. This is essentially how DNA works: by recombination of existing genes and their alleles.

Holland was one of the first to create evolutionary models for rule-based decision-making, which earned him a reputation as the father of genetic algorithms. He not only convincingly described how these performance systems are an interesting conceptual model for complex adaptive systems, but he also showed that they can be implemented easily to create evolutionary algorithms with powerful problem-solving capabilities.

Why am I writing all this?

For one reason only: to help people understand that rule-making is something that must happen bottom-up. And not top-down.

Science proves it.

(image by Syntopia)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
Self-Organization vs. Emergence
Self-Organization vs. Anarchy

Making good and steady progress.  I’ve made higher and higher scores on some of the multi-player games, but unfortunately I can’t seem to save and track my ongoing progress on those.  Of course, my son regularly humiliates me on the snowball fights so maybe I should be grateful for no tracking!

• Weight — Down 4.5 lbs from week 2 (249 from 253.5)
• Wii Age — I’m still at 55, though the missing week’s age turned out to be 45.

The balance tests are still a bit of a problem.  I’m standing straighter — my center of balance is just about in the middle now — but I still have some issues w/ shifting my weight.  Also, I find that my right leg is feeling the workouts more.  There clearly was something I missed in rehabbing from my long-ago broken pelvis.

Filed under: PMO Tagged: capabilities, capability building, deliverables, goal-setting, KPI, New Year's Resolutions, performance reporting, weight loss, Wii, Wii Fit

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

I'm attending a National Defense Industry Association conference on Program Management. I took a break to read some emails - you can only take so much of Earned Value, probabilistic cost modeling, a DCMA self assessment audit guidelines.

There's a discussion going on about how agile software development methods can be applied to safety critical systems. First I earn my living working on programs that contain safety critical system. As well I designed and deployed a safety critical system - the Tricon a classic 80's product name.

The discussion from the agile point of view is typical agile - we've got this really cool way of doing things, you can use it on your problem too.

In the absence of a domain and context, probably not. I spoke for two nights this week at Carnegie Mellon University, San Jose on the 5 immutable principles of project management. My co-speaker is a senior manager at Pay Pal, which make very good use of Scrum in the development and maintenance of its code base.

One of the learning from that series of lectures is that a software development method needs to have a domain and context for it to be effective. If we say a development method is valuable in the absence of that domain and context, we are following Mencken axiom

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

The Generic Project Schedule By Clifford Ananian Although every project is unique, and its execution plan is specific to its goals and objectives, there are some common rules and tendencies of project schedules that are not project specific. The purpose of this article is use a simplistic “generic” schedule to illustrate some of these rules and tendencies. The [...]

I recently watched a Hindi movie called 3 Idiots. The moral was... Sanjay Saini, PMP