|
Amazon
No Wishing Required
Prinzo Group eBook Store
Category:
Business/Investing
Publisher: The Prinzo Group
ISBN-10: 0983033544
Pages: 150
Copyright: October 1, 2010
ISBN-13: 9780983033547
No Wishing Requiredis the story of a project team navigating the complex world of enterprise software implementations and their quest for project success. Led by Jenny, the ambitious, yet sometimes naïve project manager, No Wishing Required takes the reader through Jenny’s journeys and struggles with a major system implementation that is on the brink of failure to the challenges of the company’s latest project: a complex multi-step system upgrade / transformation project. Through the guidance of her new manager, Bill Parker, Jenny discovers that there is a way to assure project success that really works: collaborative intervention.
While it is fiction, the experiences and characters in No Wishing Required will resonate with anyone who participated on a large business systems implementation project team. Through the story of Jenny, Bill and the project team, you’ll discover the power of collaborative intervention – what it is and how to use it. You’ll find a step-by-step process complete with tools and techniques for proactive and effective project leadership.
Short of a Genie, collaborative intervention is the only methodology designed to help you avert project failure before it occurs. And best of all, there’s no wishing required.
Excerpt
Rob Prinzo: The story behind No Wishing Required
Ever wish that you had done something differently? Sure, we all have. But you can’t change the past; you can only change the present and the future, which is why I wrote this book. It‘s about collaborative interventionSM – what it is and how to use it. Short of a Genie, it is the only methodology designed to avert project failure before it occurs.
For more than fifteen years, I’ve been in the enterprise software implementation field. Let’s face it, it’s a non-glamorous, complex field aimed at implementing administrative systems for large companies and governments that are looking to automate, and hopefully, improve business functions using technology applications.
Software implementation is actually my second career. My first was a short-lived stint as a grad student working toward a PhD with the goal of being a college professor. During the recession of 1992, I was unable to find a job that I was interested in. I was given the opportunity to work as a graduate assistant for the research arm of the University. I was to sell a software package to apparel and textile manufactures. Despite the fact that the U.S. apparel and textile industry was pretty much doomed, I took the job because it was interesting and it allowed me to stay in school while I earned my Masters Degree. Better yet, I could continue to avoid the real world for a couple more years.
Despite my less than stellar academic record as an undergraduate, I found graduate school very interesting because I could apply academic concepts to the practical application of my work with apparel and textile companies. I was pretty good at putting conceptual models together to explain business processes and my work even won a couple of industry sponsored scholarship contests. As I progressed through grad school, when I reached the point where I needed to commit to the PhD program, I realized I didn’t like the academic research required to support my models. The research was less about the model itself and more about the statistics supporting the findings. It must have been pretty obvious at the time – I was even pulled aside by a professor who, even though he liked my work, said it was better suited for practitioners.
In 1995, I left graduate school to take a job with Dun & Bradstreet Software as an implementation consultant. The timing was good. Companies were beginning the transition from mainframe green screen systems to relational database technologies with graphical user interfaces or GUIs. Companies were also facing the doomsday scenario known as Y2K. The fact that new technologies – first client server and, soon after, the Internet – were being introduced at a time when organizations needed to make changes to their outdated systems created the perfect storm for the enterprise applications software industry.
The next five years were a rollercoaster as we rode the ERP/Y2K wave. Demand for implementation consulting services was so high that consulting firms could not keep up. The technologies were so new that consultants were literally days ahead of the clients in learning the software. The results were mixed: Y2K was averted, but organizations were left with less than optimal systems that weren’t properly implemented. Countless papers and articles were written on project success rates and why projects failed. All experts agreed on one thing: surely we have learned our lesson and things will be different moving forward.
I am not so sure about that.
Fast-forward ten years to 2010. The economic downturn and great recession have had significant impact on enterprise systems as many organizations are facing the need to upgrade. While the economy remains in uncertainty, spending on enterprise applications and IT has not changed. Most organizations have halted spending on enterprise business applications, because for the most part, the business can get by with what is in place.
In actuality, the longer an organization waits to upgrade its technology, the more the upgrade will cost. Also, similar to Y2K, several driving external factors are influencing the enterprise software decisions and will likely play a role in your next technology project: consolidation and shared services, software as a service and outsourcing.
Given the economy and other external influencing factors, it is likely that you will have a big project in your future. It may be an application upgrade, a transformation project or a move to an outsourced platform. In any event, it will be complicated. Many organizations are internally integrating systems that cross traditional business functions and externally have more vendor partners involved in technology projects. The result? A complex soup of internal and external project team members, motives and goals.
And here is that pesky statistic again: despite the cumulative knowledge gained from decades of implementing enterprise systems, industry analysts are still predicting that projects have a 70% rate of failure. That means you only have a one in three chance of succeeding.
On closer examination, we really shouldn’t be surprised. The reasons that projects fail are the same today as they were ten years ago: lack of top management commitment, unrealistic expectations, poor requirements definition, improper package selection, gaps between software and business requirements, inadequate resources, underestimating time and cost, poor project management, lack of methodology, underestimating impact of change, lack of training and education, and last, but not least, poor communication.
I can chalk up what happened with Y2K implementations to the fact that we really didn’t know what we were doing or to the oppressive deadline that forced things to happen too quickly. But today, we are still seeing 70% failure rates – and if these are caused by the same factors, something is fundamentally wrong.
Fifteen years from now, are we going to look back and wish we had done things differently?
Which brings me back to why I wrote this book. It’s about making projects fail-safe. I call it project assurance through collaborative intervention. Project assurance is a disciplined practice developed to deliver projects on time, on budget with user acceptance. Collaborative intervention is the breakthrough methodology I have developed and used to obtain project assurance. Collaborative intervention addresses the gaps that lead to the reasons projects fail. Collaborative intervention provides you with a framework and process for closing these gaps.
To some, this collaborative intervention approach may seem overly simplistic – but that may be the point.
Often, we become so engrossed with project status, metrics, and management concerns, that we overlook addressing the root cause of a problem. A problem may be obvious, but the solution, such as increasing top management commitment or changing unrealistic expectations, is not. Let’s be honest, collaborative intervention is pretty tricky and relies more on our ability to change and influence human behavior than on our abilities to update a project dashboard or conduct a fit-gap session. It also requires project leadership, not just project management. And, to further complicate things, the leadership may need to come from someone who is not in the position of authority, but who needs to convince the people in positions of authority that change is required for project success.
That’s the reason I wrote this book.
There is a way and it does work.
No Wishing Required tells a story of business people who are involved in enterprise system implementations. While it is fiction, it is based upon real experiences – good and bad – relating to project management and implementation of enterprise applications technology. This book is both a business documentary of professional growth as well as a cautionary tale for those who don’t want to repeat the past in the future. The central characters in this book: Jenny, Bill, and the FirstCorp project team, are fictional. Any resemblance to actual people or events is purely coincidental.
Having said that, I hope you enjoy No Wishing Required. If you like this book, please recommend it to a friend or colleague. It is my wish that you find value within the concepts of this book and that you, or someone you know, does not look back after the next project and say, “I wish I had read Rob’s book first.”
Godspeed my friend,
Rob
©2010 Rob Prinzo. All Rights Reserved. Collaborative Intervention is a service mark of Project Wing, LLC.
|
