All Posts in Project Management

|In: App Dev Methodologies|Last Updated:

I’m giving myself a Memorial Day break. I didn’t post anything yesterday, and today is a re-run, from, as the Beatles might have sung, 20 years ago today.

It’s a bit esoteric, but even more relevant today than when I first wrote it.

Take a look and let me know what you think about it.

– Bob

# # #

If there’s one certainty in our business, it’s that useful, lightweight frameworks turn into bloated, productivity-destroying methodologies.

And so it was with considerable trepidation last week that I suggested we need another methodology, to do for Content Management Systems (CMSs — the technologies we use to manage unstructured information) what normalization and related techniques do for relational database management systems (“Unstructured data design — the missing methodology,” KJR, 5/17/2010).

But we do. As evidence, I offer many of the comments and e-mails I received suggesting we don’t: Most pointed to the existence of well-developed tools that allow us to attach metadata to “unstructured content objects” (documents, spreadsheets, presentations, digital photos, videos and such, which we might as well acronymize now and have done with it: For our purposes they’re now officially “UCOs”).

And many more pointing out that search obviates the need for categorization.

Let’s handle search first, because it’s easier: Search is Google listing 16,345,321,568 UCOs that might have what you’re looking for. It’s also what leads to (for example) searches for “globe,” “sphere,” “orb,” and “ball” yielding entirely different results.

Search is what you do when you don’t have useful categories.

And then there’s metadata — the subject that proves we don’t have what we need. Because while we have the ability to attach metadata to UCOs, we have only ad hoc methods for deciding what that metadata should be.

Some readers suggested this might be a solved problem. Books are UCOs, and librarians have been categorizing them for centuries. Between the Dewey Decimal System and the Library of Congress Classification, surely there’s a sound basis on which to build.

Maybe there is. I’m skeptical but not knowledgeable enough to state with confidence they won’t work. I’m skeptical because their primary purpose is to place books in known locations in the library so they can be readily found, which means they’re probably similar to the single folder trees we need to move beyond.

What we need, that is, is the ability to place one UCO in as many different locations as anyone might logically expect to find it. To use one of my own books as an example, Leading IT: The Toughest Job in the World would fit in at least these categories: Leadership, Information Technology, Staffing, Decision-making, Motivation, Culture change, and Communication skills.

The official name for the discipline of defining knowledge domains … what we’re trying to do … is ontology. It’s an active area of development, including the creation of standards (such as OWL, which puzzlingly stands for “Web Ontology Language” instead of “Ontology Web Language,” but let it pass).

From what I’ve been able to determine, though, it appears everything being developed thus far falls under the heading of tools, with a useful methodology nowhere in sight. This is, perhaps, unsurprising as it appears philosophers have been discussing the subject at least since Aristotle first introduced it 2,350 years ago or so, without yet arriving at a consensus.

It could be awhile.

Of course, philosophers are obliged to develop systems so universal they apply, not only to our universe, but to all possible universes. Such is the nature of universal truth.

We don’t need to be quite so ambitious. We merely need to categorize information about our businesses. To get the ball rolling, I’ll offer up the framework we’ve synthesized at IT Catalysts. It enumerates ten topics that together completely describe any business — five internal and five external. They are:

Internal

  • People: The individual human beings who staff a business.
  • Processes: How people do their work.
  • Technologies: The tools people use to perform the roles they play in business processes.
  • Structure: Organizational structures, facilities, governance, accounting, and compensation — how the business is put together and interconnected.
  • Culture: The learned behavior people exhibit in response to their environment, and the shared attitudes that underlie it.

External

  • Products: Whatever the business sells to generate profitable revenue.
  • Customers: Whoever makes or influences buying decisions about the products a business sells.
  • Pricing: What the business charges for its products, terms and conditions of purchase, and the underlying principles that lead to them.
  • Marketplace: The business “ecosystem” in which the company exists, including customer groupings, competitors, partners, and suppliers.
  • Messages: How and what the business communicates with its marketplace.

There you go — a free gift, if you’ll forgive the redundancy. Just break these topics down into sub-topics and sub-sub-topics. The result should be a workable classification scheme.

Let me know when you’re done.

Comments

|In: Leadership|Last Updated:

You’re managing a project. What can go wrong?

Well …

Scenario #1: It’s hard to overcome the CEO

A friend managed a business transformation tied to a large software suite (I’m not allowed to be more specific). Her client was a multinational concern that wasn’t wise in the ways of project management. She had a strong team, the right work breakdown structure, a good working relationship with the vendor, and a committed executive sponsor.

But then the CEO happened. All by itself, just one restructuring would have driven quite a bit of re-work into the project. Multiples multiplied the impact.

And that’s before the ritual laying off of several people the project couldn’t do without. As The Mythical Man Month makes clear, replacing these key staff slowed things down even more, as the effort needed to acclimate the project newbies to the project and their responsibilities exceeded any benefit they could provide.

My friend got the project done, but it got done much uglier than it needed to.

Lesson learned: Include a list of specific critical personnel in your project Risks and Issues reporting, and make sure that reporting is visible at least one layer higher than the project’s sponsor. It won’t completely prevent the chaos, but it might reduce it.

Scenario #2: A filter that should be a conduit

So you say your executive sponsor cares deeply about your project’s success. You say he’s assigned the right people to the core team, and has let everyone else know they should support the project when their support is called for.

And … he’s a busy guy, so he’s delegated day-to-day sponsorship to a trusted member of his team, who is to be your primary Point of Contact. His busyness also means he has no time for regular face-to-face updates.

But not to worry. Your PoC meets with him weekly, and will keep him informed.

As the project progresses, unexpected discoveries drive a number of course corrections. Taken one at a time, none seem particularly controversial, so you and your PoC make the decisions and move on.

A couple of months later, though, with a major milestone approaching, you bring the sponsor in for a briefing. That’s when you discover that what seemed minor to you seems less minor to your sponsor, and the decisions you and your PoC to resolve the issues weren’t the solutions the sponsor would have chosen.

This is when you find out your PoC either hasn’t embraced the “bad news doesn’t improve with age” dictum or also didn’t think the issues in question were important enough to mention in his weekly updates.

And, it’s when you first figure out the sponsor defines “handled correctly” as “how I would have handled it,” and “handled wrong” as “all other ways of handling it.”

So now you have an irritated sponsor and a project schedule that’s in recovery mode.

You can’t entirely avoid this. What might at least help is, prior to your PoC’s weekly meetings with the project sponsor, rehearse the topics to be covered in the project update.

Scenario #3: EPMO — enabler or bureaucracy

Congratulations! As a result of your many well-managed projects and the value they delivered, you’ve been promoted to the Enterprise Program Management Office — the EPMO. In your new role you’re responsible for ensuring all project investments are worthwhile, and providing oversight to make sure they’re well-managed by project managers who aren’t you.

And so, guided by “industry best practices,” you establish a governance process to screen out proposals that don’t make the grade.

Then you start to hear those governed by the EPMO use the B-word in your general direction. No, not that B-word. Bureaucrat.

Which, if you think your job is to screen out bad proposals, you’ve become.

First and worst, a bureaucrat evaluates proposals. A leader evaluates the ideas behind the proposals.

Second and almost as worst, if you expect to see dumb ideas you’ll see dumb ideas, because most people, most of the time, see what they expect to see. And anyway, if what you do is screen out dumb ideas you’ll pass the proposals that don’t give you a reason to screen them out, not those that give you a reason to keep them in.

So take the B out of your job. Starting tomorrow, the EPMO’s job is to help good ideas succeed.

Followed by your stretch goal: to help turn good ideas into great ones.

Comments