[irq]: serially techie

representing non-linearity in project execution

Typically, projects are broken down into constituent activities and tasks and then presented as a two-dimensional process proceeding linearly through time. The overlapping, looping, and conditional flows of activities in an actual project tend to get lost. Critical go/no-go decision [i.e. inflection] points, if identified, are not accurately placed in time or process.

Project management software sucks and is workflow ignorant.

From both the execution side and the client side, misunderstandings (and associated risks) pile up—caused by trying to cram complicated workflows into oversimplified procedural representations. This old hat to most people who run projects or work in the services business. But, there are few approaches to resolve this issue that aren’t mostly manual.

Why don’t people who run projects just use flowcharts? Flowcharts don’t map well to time.

Instead of presenting activities in a “1 then 2 then 3…” fashion, they could be presented as dependency clusters separated by critical milestones-in process and time-that are go/no-go decision points. Each go/no-go decision could then have an associated set of actions undertaken depending on the decision: continue, return to activity x, etc.

portfolio vs go-to-market

[Context: technology services business.]

The portfolio is composed of service offerings. Who delivers the services and how is highly variable, but it only matters that they can be delivered. In general, there’s a 1-to-1 between the services in the portfolio and those sold in the marketplace. That which is marketed is a discrete element in the portfolio.

Marketing messages come and go. Things that clients need (and think they need) come and go. “Solutions” come and go. But skills and delivery capabilities are much less volatile over time. The portfolio represents both an internal capability (to deliver a particular service) and an external presentation of that capability to the marketplace. When there’s a 1-to-1 between the two— 1) the go-to-market becomes brittle because these things change at differing rates or 2) the portfolio becomes littered with things that don’t make sense, overlap one-another, etc., in order to match the moment’s marketing vogue.

If you break the 1-to-1, then the portfolio can represent an internal capability while the go-to-market represents the set of solutions that are selling, that will sell, and that you want to sell in the marketplace. What parts of the portfolio make up any given solution become variable and go-to-market solution development becomes a composition task. If and only if a legitimately new service capability is needed to deliver a solution, such capability is developed and added to the portfolio.

These tools should not be sources of brittleness and inertia, but instead of flexibility and competitive advantage. Make’em so.

The portfolio != the go-to-market.

service productization notes

[Copied and modified a little from a 1yr-old post on my now-defunct blog.]

How services should be treated like products:

• Development lifecycles. Processes that: identify the triggers in the marketplace, in technological innovation and research, in services delivery innovation and research, sales statistics, etc. that should initiate changes to a service offering; define how changes are made; define how new offerings are developed.
• Version control. Track changes, freeze offerings for deployment, maintain stable vs developing offerings, etc.
• Testing. Process for alpha/beta testing offerings with sales/biz dev, delivery, partners and clients.
• Ecosystem. A community of clients and partners willing to test out new/changed service offerings.
• Components. Decomposition of services into component service elements, assets, patterns, etc., a la SOA/SCA.
• Descriptions. Standard format for service offerings identifying content/service elements; assets; and a standard set of properties such as “line of business”, “sectors”, “technologies”, etc.
• API. Standard interface into and out of service offerings allowing components to plug into each other, allowing partners to integrate your offerings into their portfolios and vice versa—in effect, a services product portfolio API.
• Customers pay for something. Stop charging by the hour. If you’re really going to be an asset-based business, that is.
• …what else?

• Sales. No one gets commissions or bonuses unless their deals generate profit and then only to the extent to which they do. If that’s too radical, replace “profit” with “revenue” and go from there.
• Cost model. Costs for developing, testing, delivering, and establishing maturity in a service offering are radically different from products—because the factors are radically different. And then, some of those very factors vary from offering to offering.
• Scaling. Services do not scale easily. Because people don’t. Because brains do not scale. The less knowledge/skill required, of course, the easier it is to mitigate this issue.
• …what else?

asset-based [services] business

[Copied and modified a little from a 2yr-old post on my now-defunct blog.]

What’s an asset? Not a person. Services is a labor-based business. Everything is ultimately thought of in terms of hours billed (to a contract and ultimately/hopefully a client) vs hours costed (not billed ultimately to a client). Every hour a person spends that’s not billed is a cost to the organization. Every hour billed is recovery of that cost and hopefully generation of some profit. This is grossly oversimplified, but in essence accurate.

People accrue experience, knowledge, and skills. People also vary. And they don’t scale well. You want to get the best of what’s in one person’s head into others’ heads. You don’t want all that accrued stuff to leave with them when they move on. Thus intellectual capital—-all the processes, methods, lessons-learned, etc., encoded in patents, white papers, redbooks, best practices papers, homegrown tools, spreadsheets, databases, etc. The latter are “assets”. An asset-based business is one that focuses on the development of assets and considers them the prime value-delivery vehicle (as opposed to people). So you move from people delivering services to people using assets to deliver services. It introduces a manageable (you hope), lifecycle-able middle man (or abstraction layer) between the people and the value being delivered. So the people can become relatively interchangeable—skill level, etc., being equal—as long as the assets are kept up to snuff.

It’s a step towards consistency, standardization, globalization, and scaling.

Note: I haven’t said anything about how much I do or don’t agree with this approach.

what I do at ibm

I get asked this a lot. It’s basically the equivalent of product management in the professional services business.

I’m a global service product manager = globally responsible for the management of some “service products”, which is what IBM Global Technology Services calls its service offerings. I’m on a small team that holds responsibility for developing and maintaining standard project-based (as opposed to outsourced) service offerings in the data center networking realm that are executed by network architects, consultants, and specialists around the world. Note that it’s a global team: our stakeholders are the local business unit leaders in each geographic area where we do business, who are a lot closer to where P&L is owned. You can read more about the kinds of projects I do on linkedin.

This involves the whole lifecycle of a service offering: from gathering the market research, getting briefed by vendors, building the business case, developing marketing materials, creating global contracts, etc.; to developing education programs, promoting inside and outside of the company, assisting in initial pre-sales activities, etc.; to making updates when technologies or architectures change in some important way, etc.; to pulling an offering from the marketplace when it no longer serves any significant client need or isn’t making enough money.

As if that weren’t enough, I’m also a bit of a busybody and get my hands into all kinds of other things: strategy work around networking, portfolio management, social media, messing with core services business processes, vendor management, development of our internal networking reference architectures, heckling people in charge of things….

[Editorial note: sorry for the long, perhaps hard to follow sentences.]