Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint.   I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:

• On balance “no Blueprint” is good.  Its exclusion reinforces that a RDS implementation is of a fixed, limited scope.  There must always be some sort of scope statement, of course, and its there.  Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries!  Wise to make a clean break in the lexicon.
• Avoid Death by Change Order.   RDS is designed to deliver only what one needs to execute — the wish list comes later.  Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into  backlogs that get burned down release-by-release. 
• RDS still too “new solution” oriented.  There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?

Filed under: PMO Tagged: ASAP, Dennis Howlett, Mark Chaffen, RDS, SAP

Pro .NET Best Practices gets a great review from Tad Anderson in the .NET Developer’s Journal http://t.co/I0W5P4lL. 
I loved the reviewer’s lede:

I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed.

Filed under: PMO Tagged: Development, Project Management

Flight of fancy...now boarding!

My first thought when I saw this post by Glen Alleman was ”cargo cult“. 

I’m wary of concepts from hard sciences that find their way into business jargon, largely because the concepts become incantations.  It feels like we’re appropriating the prestige of science, just like a cargo cult’s “focus on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices.”

In other words, I cringe when I hear incantations like — “complexity”, “emergent”, etc. — as if the words in and of themselves suffice.   It’s nothing but meaningless superstition without insight and actions that solve problems or exploit opportunities.

Filed under: PMO Tagged: cargo cult, Complexity, Emergence, Glen Alleman

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

Filed under: PMO Tagged: analogy, Data Model, ERP, Glen Alleman, Process Model, SAP

When Vladimir Lenin posed this question in 1901, socialism was riven.  Most early Marxists believed that the core prediction of Marx’s theory — an inevitable proletarian revolution — was just around the corner.  But by the turn of the 20th century, the revolution appeared farther away than ever.  If anything, the contradictions among the classes were cooling in advanced capitalist states, not boiling over.  

So why the two-bit summary of a turn-of-the-20th century dispute among socialists?  Simply this: Lenin’s pamphlet paved the path for revolutionaries around the world.  As I was noodling on The Meaning of #Stoos, I re-read it and picked out a few things that change agents can learn from Lenin:

1. Show that you know “What Is To Be Done?”  The title itself is a clear call to change, which Lenin knew would intrigue and inspire his audience.  It also hints that he had the answer.
2. Show that you know the problem  Lenin realized that Marxist theory was a powerful “call to take the field against the enemy.”   But its guidance was so focused on the economics of workers vs. capital  that most volunteers went into “battle with astonishingly primitive equipment and training.”  Success would take a group of professional revolutionaries  using “all the rules of the art” of organizing.  Furthermore, his arguments hit hardest at the premises of his adversaries; in other words, he not only didn’t argue on their terms, he argued that their terms were part of the problem.
3. Professionalization can make change dangerous.   Lenin’s point won the day.  Now just about all revolutionaries prefer professional, vanguard-led organizations.   Even corporate change is driven this way; nearly every transformational project engages professional change experts.  But if small, apparently imperceptible changes can make things worse — Steve Denning has a great product anecdote here — what can happen when professionals turn things upside down…on purpose? 

I’ll get back to this topic later…

Filed under: PMO Tagged: Marxism, Organizational Change Management, Stoos, Vladimir Lenin

Nice post here by Hass Chapman on hunter-gatherers, play & software development.   I can definitely relate to the way of working outlined.  While we were hunter-gatherers, we did take to agriculture eventually. 

That move is not natural for me, though.  I’m more of a rancher than a farmer.   The challenge for me, therefore, is how to accommodate other styles of work. 

To highlight potential role mismatches, I fall back on models like the “finders, grinders, minders” consulting model David Maister popularized.   Consulting comes to mind because I’ve often heard customers say: “I’d like the folks who built it to be the ones who support it.”  That sounds plausible in theory, but that usually involves taking a “grinder” and making him/her a “minder”.  Which rarely works unless that person is explicitly looking to change his/her lifestyle.

Filed under: PMO Tagged: Hass Chapman, Vocation, work-life balance, workmanship

Michael Krigsman received a lot of good feedback on his post about getting IT and business together. The second point was top of mind as we’re standing up new and improved architecture governance.

A basic governance checklist can catch the type of folly Michael describes. A project that proposes to create an app entirely from scratch — like Michael’s example — should stand out as an initiative to receive heightened scrutiny. Well, it should if you have a set of standards! But that’s another post!

Filed under: PMO Tagged: architecture, CIO, Michael Krigsman

I loved this Atlantic piece about “pocket neighborhoods”, though the suburbs weren’t the application that first came to mind.  This design philosophy appears perfect for those “blighty” neighborhoods I see in town, just off the core.  They’re often convenient locations that become marginal because of a dodgy block or a rundown house (or three). 

Unfortunately, most of our redevelopment arsenal destroys the village in order to save it.  I’m not just talking about old-school urban renewal with its high-rise projects and sterile plazas.  The mixed-use redevelopment now in vogue tends to a gigantism that overwhelms the character of the surviving neighborhood, even if there’s a nod to affordability in the planning.  On the other hand, single home approaches — think Habitat for Humanity — can fix a house or two.  However, they can stick out like a crude cap on a broken tooth.

Pocket neighborhoods are an intriguing response to this challenge.   They have enough scale to completely repair parts of bad blocks – like a well-fitted crown replaces a bad tooth — while connecting to the still-vibrant villages beside them.   If well done, they also don’t scream “I’m poorly-built affordable housing”!

Filed under: PMO Tagged: pocket neighborhoods, redevelopment, Reihan Salam, The Atlantic, urban renewal

Dan Markovitz at Timeback reminds us that performance reviews are a dangerous exercise. Even if we grant their utility,  they have a profound credibility gap to bridge.

Leaders must go into performance discussions with a humble heart.  As Dan’s notes, your colleagues likely will be very skeptical about the usefulness of those chats you’re about to have.

Filed under: PMO

Glen Alleman suggests that you download this and put it to work on projects.  However, for some the defense focus and jargon are daunting or off putting.  My suggestion for putting this guidance to work: first transform the tables into a checklist or two. 

1. The “validity” topic focuses you on whether a plan is ready for “prime time”.  Use this when evaluating early stage gates. 
2. The ”effective”  items are obviously relevant as one evaluates the quality of your projects’ execution.  These items should be a part of regular status reporting.

Then learn what “level of effort” means!

Filed under: PMO Tagged: checklists, communications management, integration, program plan

This question — about problems project managers impose on their projects — wraps up my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).    Remember that Stephen describes a promotion to get 40-percent-off his book at his blog here.     I hope you all found it as interesting as I did:

What are common obstacles that project managers introduce into projects?

Haste. I like to say, “schedule pressure is the enemy of good design.” During project retrospectives, all too often, I find the primary technical design driver was haste. Not maintainability, not extensibility, not correctness, not performance … haste.  This common obstacle is a silent killer. It is the Sword of Damocles that … when push comes to shove … drives so many important design objectives underground or out the window.   Ironically, the haste is driven by an imagined or arbitrary deadline. I like to remind project managers and developers that for quick and dirty solutions … the dirty remains long after the quick is forgotten. At critical moments, haste is important. But haste is an obstacle when it manifests itself as technical debt, incurred carelessly and having no useful purpose.   Other obstacles include compartmentalization, isolation, competitiveness, and demotivation. Here’s the thing. Most project managers need to get their team members to bring creativity, persistence, imagination, dedication, and collaboration to their projects if the project is going to be successful. These are the very things team members *voluntarily* bring to the project.   Look around the project; anything that doesn’t help and motivate individuals  to interact effectively is an obstacle. Project managers must avoid introducing these obstacles and focus on clearing them.
Filed under: PMO Tagged: best practices, Project Management, Ruthlessly Helpful, software development

I’ve enjoyed the bits and pieces of Stoos I’ve picked up, mostly via Jurgen Appelo‘s summaries (the discussions at the LinkedIn group have been valuable as well).  For those who aren’t familiar with the Stoos Gathering, the goal was modest, but the topic was bold:

At the Stoos Gathering we will discuss how to accelerate change in management and organizational transformation.

That’s all?  More seriously, I love the ambition and it it has been great grist for my mental mill, especially these three themes in the documents and discussions:

1. Leaders should change themselves first: A fellow named “Hank” noted this in the pre-gathering documents.  For example, leaders who have not learned to self-forget may find they struggle to build trust.  And putting spiritual traditions aside, those who have not tended to their spiritual armor will find they cannot resist the forces of reaction.
2. “The Problem” will prove a crafty and adaptive foe: Steve Demming notes that “the participants left for a future time evaluations of the best ways of getting from “the problem” to “the desired outcome.”  Wise move, because IMO these “best ways” will have to contend with Anna Karenina Syndrome: “Happy firms are all alike; every unhappy firm is unhappy in its own way.”  The solutions must be viral, in every sense of that word.
3. Beware introducing “corporate managers”: I’ve seen a desire to involve corporate managers into Stoos what Jurgen calls Management 3.0.  That’s great, but some of us are “The Problem” and aren’t self-aware enough to know it (see point one).  I’m especially concerned about two types: those who’ll want to boil it all down to “one particular approach” and those who’ll pick any work product apart as “impractical”, “not actionable”, “unrealistic”, etc.

Filed under: PMO Tagged: corporate culture, Innovation, Jurgen Appelo, Leadership, Organizational Change, personal transformation, Steve Denning, Stoos

Here’s a list from Forbes of things that kids won’t need to worry about because of the modern information revolution. 

I would have quibbled with #1 until recently.  A few days ago I saw my (almost) seven-year-old son typing away merrily with both hands.  From hunt and peck to touch typist in a few months…amazing.

Filed under: PMO Tagged: Adam Thierer, Forbes, Information Revolution, Jonah Goldberg

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.    We turn to the project manager’s role:

Q: Can you give an example or three of how project managers can be “ruthlessly helpful” to their development teams?

A: Here are a few:
1) Insist that programmers, engineers and other technical folks go to the whiteboard. Have them draw out and diagram their thinking. ”‘Can you draw it up for everyone to see?” Force them to share their mental image and understanding. You will find that others were making bad assumptions and inferences. Never assume that your development team is on the same page without literally forcing them to be on the same page.

2) Verify that every member of our development team is 100% confident that their component or module works as they’ve intended it to work. I call this: “Never trust an engineer who hesitates to cross his own bridge.” Many developer’s are building bridges they never intend to cross. I worked on fixed-asset accounting software, but I was never an accountant. The ruthlessly helpful PM asks the developer to demonstrate their work by asking things like “… let me see it in action, give it a quick spin, show me how you’re doing on this feature …”.  These are all friendly ways to ask a developer to show you that they’re willing to cross their own bridge.

3) Don’t be surprised to find that your technical people are holding back on you. They’re waiting until there are no defects in their work. Perfectionists wish that their blind spots, omissions, and hidden weakness didn’t exist. Here’s the dilemma; they have no means to find the defects that are hidden to them. The cure they pick for this dilemma is to keep stalling until they can add every imaginable new feature and uncover any defect. The ruthlessly helpful PM knows how to find effective ways to provide the developers with dispassionate, timely, and non-judgmental feedback so they can achieve the desired results.

Filed under: PMO Tagged: best practices, Project Management, Ruthlessly Helpful, software development

I liked this video via SmartBrief. The lesson applies to initial hires in any size organization. They lay the foundational deliver ables and set the bar for performance expectations.

Filed under: PMO Tagged: hiring, Leadership, team building

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.  Here we focus on why he spent so much time on PM-relevant topics:

One of the pleasant surprises in the book was the early attention you paid to strategy, value, scope, deliverables and other project management touchstones. Why so much PM?

I find that adopting a new and different practice — in the hope that it’ll be ruthlessly helpful one — is an initiative, kinda like a micro-project. This can happen at so many levels … an individual developer, a technical leader, the project manager, the organization.

For the PM and for the organization, they’re usually aware that adopting a set of better practices is a project to be managed. For the individual or group, that awareness is often missing and the PM fundamentals are not applied to the task. I felt that my book needed to bring in the relevant first-principles of project management to raise some awareness and guide readers toward the concepts that make these initiatives more successful.

Filed under: PMO Tagged: best practices, Project Management, Ruthlessly Helpful, software development

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.  

If you’re a regular reader, you’ll know I’m wary of the term best practices.  Stephen is as well, and here’s his take:

Q: Your book’s title notwithstanding, you’re keen to move people away from the term “best practices.”  What is wrong with “best practices”?

A: My technical reviewer, Paul Apostolescu, asked me the same question. Paul often prompted me to really think things through.

I routinely avoid superlatives, like “best”, when dealing with programmers, engineers, and other left-brain dominant people. Far too often, a word like that becomes a huge diversion with heated discussions centering on the topic of what is the singularly best practice. It’s like that old saying, the enemy of the good is the best. Too much time is wasted searching for the best practice when there is clearly a better practice right in front of you.

A “ruthlessly helpful” practice is my pragmatist’s way of saying, let’s pick a new or different practice today because we know it pays dividends. Over time, iteratively and incrementally, that incumbent practice can be replaced by a better practice, until then the team and organization reaps the rewards.

As for the title of book, I originally named it “Ruthlessly Helpful .NET”. The book became part of an Apress professional series, and the title “Pro .NET Best Practices” fits in with a prospective reader and booksellers’ expectations for books in that series.

Filed under: PMO Tagged: best practices, Project Management, Ruthlessly Helpful, software development

If you’re involved with SW procurement and aren’t following Thomas Otter (@vendorprisey, Gartner blog here, personal blog here), then please do so.  I saw his post on HCM SaaS/On Demand negotiations (here) and silently nodded my head in agreement.

As SaaS HCM deals come up for renewal, and procurement gets involved, it is now crystal clear that most HR departments have been contracting for HCM software without IT procurement involvement. One of our findings is that most of the time, HR departments are rather poor negotiators.

If you’re a Gartner client, then check out the research note (here, subscription required).

Filed under: PMO Tagged: contracts, HCM, IT procurement, On Demand, SaaS, software procurement

“Project management as profession” remains a fraught subject (initial post here, survey here, survey results here).  I doubt it ever will, at least not fully like law, medicine, or academia.   Furthermore, I believe that because project management is essentially a social science — i.e., a discipline about human action — we will have persistent trouble in trying to settle debates with evidence and experimentation.

To that end, Jim Manzi provides a useful summary of the epistemic challenge faced by social sciences — what they do, don’t, and could (eventually) know.   He sets up the problem in this excerpt below:

[W]e have no reliable way to measure counterfactuals—that is, to know what would have happened had we not executed some policy—because so many other factors influence the outcome. This seemingly narrow problem is central to our continuing inability to transform social sciences into actual sciences. Unlike physics or biology, the social sciences have not demonstrated the capacity to produce a substantial body of useful, nonobvious, and reliable predictive rules about what they study—that is, human social behavior….

As they say, read the whole thing.

Filed under: PMO Tagged: City Journal, Jim Manzi, PMI, professionalization, professionalization of project management, professions, Researching the Value of Project Management, ROI, science, social science, Value of Project Management

This post from @IncentIntel is timely as we head into silly season: performance and rewards time. I especially liked the two below; communications about incentives are too often treated as a ”once and done” event:

3. If the award is valuable enough you don’t need to communicate and remind them of the award opportunity.
…
5. Top performers don’t need to be reminded of where they stand in the program.

Filed under: PMO Tagged: Communications, communications management, incentive schemes, Performance Management