Software management solutions for hotels: avoiding the pitfalls
Sunday February 21st, 2016 - 4:23PM
These are shortcuts to your favorite social networking and bookmark sites. Add this story to your Facebook page, del.icio.us, DiggIt, and many others!
Learn how to avoid the most commonplace problems when initiating a software management project. Here are four big mistakes and how to fix them.
Mistake #1—Thinking that having a project manager is project management: A project manager is a professional who has studied the tools and procedures of the project management discipline and often holds a certification such as a PMP. Despite the all-encompassing connotation of the title, many people are surprised to find out the project manager’s role is rather limited. On a well-run software project, the project manager is tracking tasks, budgets and timelines.
Project management, in contrast, involves many more people. There are those who will discover and understand the business requirements; who will make strategic decisions about technology choice; and who will set the project’s goals and establish metrics. In short, good project management is holistic, not limited.
What you can do: Learn all the business roles involved in holistic project management. Many business people are not aware of the roles or “hats” necessary in a software project to achieve good governance and management, such as a project sponsor, program manager and business analyst. Taken together, all these roles achieve good project management.
Mistake #2—Not understanding the word “risk”: In regular life, when you hear the word “risk,” you probably translate it to the following statement: “There is a chance that I will endure some harm but, in all likelihood, I probably will not.”
Software development “risks” have a high likelihood of impacting budget and timeline. Many times, risks are not identified or accepted heedlessly, and timelines and budgets are blown.
What you can do: Understand the most common project risks, and account for them in timeline and budget.
Every software project has risks. Getting the definition straight—that a risk is likely to have consequences—is the first step.
Next, you must identify your risks. Most businesspeople do not know how to identify risks in a project. Consider these five items for your risk column: 1) 1ntegration: the need for one system to exchange data with another;
2) data migration: porting data from an older system into the new one; 3) customization: inventing a novel feature or function; 4) unproven technology: employing a new/hot technology just introduced; and 5) too-large project: tackling a massive project in one fell swoop rather than breaking it up into parts.
Sometimes, risks can be avoided. If a business leader is aware of risky items and their likely consequences, he or she can eliminate features in a project or put the kibosh on some sexy new technology an influential cadre of people want. When risks are identified and accepted, contingency budget and timeline should be set aside to deal with them.
Mistake #—Not understanding the accuracy of the budget: There are four methods of budgeting in software development: 1) comparative budgeting: when a vendor or internal team uses a recently completed equivalent project to estimate a new project; 2) bottom-up budgeting: when a detailed list of tasks exists and can be estimated one by one; 3) top-down budgeting: usually on a large or innovative project where few equivalencies can be identified, and it is not practical to develop a detailed list. The team estimates big “buckets” and how long they will take; and 4) blends: a budget that involves two or more of the above.
As you can probably tell from the previous list, the accuracy of the budget will vary according to the method used. Comparative budgeting and bottom-up budgeting are generally more accurate than top-down budgeting.
A businessperson may not understand why a current software development project is going over budget. He may say, “I did a project last year that seemed very complicated, and it came in on time and on budget. What is wrong with you people?”
He may not understand that his previous project was comparison-budgeted against a very similar project. The current project required top-down budgeting based on its degree of innovation. Top-down budgeting is almost always less accurate than comparative budgeting, where a good recent equivalency exists.
What you can do: Understand how the budgeting methods work.
Understand the different software budgeting methods and know which were used in your project. Set aside contingencies for the methods that are less precise.
Mistake #4—Business leaders shirk their responsibilities in project management: Business leaders with little experience in technology often raise their palms to the sky and say, “I don’t know. What should we do?”
After a few interactions like this, a group of programmers may think, “It’s my responsibility to decide.” Many organizations get into enormous amounts of trouble and expense because all strategic technology decisions are being made by mid-level programmers who have no insight into any of the organization’s actual strategy. Business leaders end up discovering too late that their customer database is a mess or that they are in violation of federal data-protection guidelines.
What you can do: Step up! It’s critical for organizational leadership to accept that however unprepared they may feel, they are in charge of making strategic technology decisions. This means involvement in software project management—in the holistic sense.
Anna Murray is a technology consultant and the CEO of emedia, llc. She is the author of the upcoming book in the Wiley CIO series, The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond.
Tags: • Hospitality •
Share your memories and moments with readers of Hotel Business as we celebrate our 25 years in the upcoming May 21st issue. We know you have great stories to tell and we want to hear from you!