Although there are many books of methods and tools in different areas, few books actually give detailed tips and lessons on how to effectively set up and manage projects. Most books on project management devote all their space to specific methods. Breakthrough Technology Project Management, Second Edition provides tangible guidelines through examples and suggestions to help people participate in and manage projects more effectively. The authors' techniques and guidelines have been proven over the past 15 years in courses and counseling. This book is a valuable tool for those working in information systems, engineering, computer science, operations and production, and other environments involving project management.
The authors were motivated to write the book due to the high failure rate of IT projects, often stemming from oversight. It is noteworthy that these observations were made around 2000, and many improvements have occurred since then.
For example, conventional project management follows a structured process: (1) business units generate ideas and justifications, (2) a steering committee prioritizes and approves selected projects, and (3) detailed planning outlines tasks and milestones. Projects typically conclude with a formal signoff, emphasizing success to avoid the perception of failure, even when desired benefits are not fully realized. The authors noted that certain practices could be improved, such as treating projects as interconnected rather than isolated, holding monthly cross-project meetings, automating project monitoring and reporting to maintain business value, and making efforts to capture and apply lessons learned for future projects.
The authors share valuable experiences, but the book's format is less effective, resembling a series of checklists best used as a manual. The language is abstract and dry at the start. While the concepts are well defined, one may only appreciate them after experiencing project management firsthand. The content focuses heavily on navigating and managing risk, with significant emphasis on lessons learned. It may be more practical to use the book through an LLM-trained consultant to address these issues more effectively. That said, there are some valuable takeaways:
Aligning IT projects with business processes: Timeless project goals include profitability, cost-effectiveness, and efficiency. However, IT projects can sometimes lack alignment with business processes, focusing too much on the technical side. Users may not fully understand their requirements initially, and business needs naturally evolve as they interact with the technology. A project should conclude when business processes are improved through system implementation, not just when the software is operational.
Continuous improvement through lessons learned: While projects have unique aspects, they share commonalities that benefit from an organized process and feedback loop. Starting with a template, gathering lessons learned, and revising the template leads to continuous improvement. This cycle—Templates → Project Plan → Issues → Lessons Learned → Updated Templates—supports cumulative enhancement. Incorporating lessons learned is an essential part of knowledge management.
Issue-focused project updates and traceability: Project updates should focus on issues rather than status. Issues should be identified with contingencies, avoiding risk-hiding padding. An issues database approach can be effective, involving a master list of issues across all projects, a project-specific issues list, and an activity tracker for follow-up. Task traceability requires creating and monitoring issues.
Balancing project and routine work with strategic planning: There is often a lack of resource management between projects and regular business operations. Much system work involves operations, maintenance, and enhancements, which take up half of staff time. Yet, maintenance and enhancements often receive less attention due to limited cost justification. Properly identifying benefits and structuring these efforts can lead to better project outcomes. Excessive focus is given to the mathematical critical path, defined as the longest project path where any delay affects the timeline. However, this path does not always include the highest-risk tasks. Any project plan should have three versions: a baseline plan, an updated schedule with revised tasks, and future high-risk estimates.
Key considerations for adopting new project technologies: When adopting a new project package or technology, many companies replace legacy systems with standardized, integrated software to reduce development efforts, lower maintenance, and increase flexibility. However, risks exist when business processes do not align with the software, requiring custom changes. Key considerations for selecting a package include business process compatibility for maximum benefit (not just lowest cost), potential behavioral changes across departments, the learning curve and consultant costs, increased departmental workload, and legacy system integration. Evaluate software and support requirements by reviewing each business transaction step and documenting progress. Choose a consultant before selecting a package, prioritizing benefits over costs, which should include hardware, consultancy, and internal support. Conduct a pilot project involving IT, the vendor, consultants, and business stakeholders.