The Handbook Of Technology Management By Hossein Bidgoli

Getting Your Head Around Bidgoli's Handbook

I keep running into people asking about The Handbook Of Technology Management By Hossein Bidgoli like it's some kind of magic toolkit you can just pull down and start using. It's not. It's a reference. A thick one. Multi-volume, heavily cited, covering everything from IT governance to technology lifecycle management and the policy side of things. You don't "apply" it. You consult it when you're stuck on something that doesn't have a straightforward answer in your company's internal documentation. Here's what people miss when they first crack it open. The handbook is organized thematically, not procedurally. There are no step-by-step workflows for implementing COBIT or aligning IT with business strategy. It gives you frameworks, models, and decision matrices. The actual implementation depends entirely on your organization's size, industry, and maturity level. I learned this the hard way. About three years ago, I was tasked with building a technology governance framework for a mid-size healthcare org. We had maybe six weeks before an audit. Someone recommended I use The Handbook Of Technology Management By Hossein Bidgoli as the foundation. I went in expecting a ready-made framework I could adapt. Instead, I found maybe 400 pages of conceptual models spread across six chapters, each one referencing two dozen other governance standards without ever saying which one to prioritize. We ended up spending more time cross-referencing COBIT 5, ITIL v4, and NIST 800-53 than we ever spent directly in the handbook.

The handbook works best when you already know what you're looking for. It's a directory of approaches, not a manual. If you're trying to figure out technology risk assessment methodologies, flip to the risk management section and read the decision trees. If you need to understand how to handle technology obsolescence in a regulated environment, the lifecycle chapter has the models you need. But don't expect it to tell you which regulatory standard to follow. That part is still on you. One thing the handbook gets right that a lot of other texts get wrong is its treatment of technology management as a cross-functional discipline. Most books treat IT as either purely technical or purely business. Bidgoli insists it's both simultaneously, and the sections on strategic alignment and organizational structure reflect that. The practical implication is that when you're designing a technology governance process, you can't just hand it to the CIO and walk away. The handbook's model assumes a steering committee with real authority over budget, procurement, and vendor decisions. I've seen too many orgs build the framework, present it, and then watch it die because procurement wasn't at the table. There's also a section on performance measurement that I come back to regularly. It's not flashy, but the balanced scorecard approach for technology management is solid. The trick is that most people stop at the four standard categories and miss the linkage layer. The handbook explicitly maps how each KPI connects to the next. Revenue per technology asset ties to utilization rates, which ties to maintenance spend, which feeds into lifecycle replacement decisions. When I build dashboards for clients, I start with those linkages instead of the individual metrics. It saves about a week of iteration per project.

A counter-intuitive point that doesn't get enough attention: the handbook's chapter on emerging technology adoption actually argues for slower evaluation cycles than most organizations run. The standard pattern I see is a six-month review for new tools, which sounds reasonable until you factor in procurement lead times and integration planning. Bidgoli's model recommends a twelve to eighteen month horizon for anything that touches core infrastructure. The reasoning is straightforward. Most technology "adoption" failures aren't caused by the tool itself. They're caused by poor change management and inadequate training pipelines. The handbook has a whole section on the human side of technology transitions that a lot of people skip because it's less technical. Don't skip it. That section alone accounts for roughly half the failure cases I've seen in enterprise rollouts. On the downside, the handbook hasn't been updated to cover cloud-native architectures in any meaningful detail. The sections on infrastructure management were written before containerization became standard, so the coverage of infrastructure-as-a-service and platform-as-a-service is thin. If you're working in a cloud-first environment, you'll need to supplement with AWS Well-Architected Framework or Azure Architecture Center docs for the infrastructure side. The governance principles still apply, but the operational specifics are missing. Another limitation is the lack of concrete examples from specific industries beyond healthcare and finance. If you're in manufacturing, government, or education, you'll be doing a lot of translation work. The models are generic enough to apply, but the case studies and references lean heavily toward sectors that already have mature IT governance programs. That means you spend more time adapting than you would if the book covered more ground.

The download situation varies depending on where you look. The handbook is available through academic publishers and major book retailers. Some institutions provide access through their library subscriptions, which is usually the most cost-effective route if your org has one. The full set runs around $400 to $600 new, so it's not a impulse buy. You can find chapter previews on Google Books and some university course sites pull excerpts, but the complete text isn't freely available anywhere legal. If you're just starting out in technology management and need something more hands-on, I'd suggest pairing this with a more practical guide like COBIT 5 Implementation Guide or the ITIL Service Strategy book. The handbook fills gaps in those resources but won't replace them. Use it when you hit the edge cases. Not before.