The major contributing factors to IT overloading are “ineffective leadership,” "insufficient resources," “de-motivated teams,” and the classic “can’t say no.”
While some IT organizations manage IT project portfolios better than others, but there’s a theme out there of project overload in many businesses, which lead to schedule slips, taking shortcuts, cost/quality misses, and then an unsatisfied customer, so what’s the root causes, and how to solve it?
1. The Causes of IT Project Overload
The major contributing factors are “ineffective leadership”, "insufficient resources," “de-motivated teams”, and the classic “can’t say no.”
- Ineffective leadership as a key contributing factor. Many times, IT doesn’t have a seat at the big table to create the strategy or functional executives hold silo thinking and unhealthily compete for limited resources, thus, they can’t prioritize and assign limited resource wisely; or work collaboratively to plan, manage, govern and measure projects.
- Strategic Leakage: In many (most) organizations, the business strategy is an archived document by which daily decisions are rarely driven. The first step is to create a situation where the main strategic performance drivers are well and commonly understood cross-functionally on the leadership team. This is where prioritization should take place; not on the solutions (projects, IT being only one ilk), but on the opportunities. The result of this exercise should be a roadmap of initiatives vs.one of projects.
- Dysfunctional roles and relationships between the "Business" and "IT." In short, if one of the parties is not up to the task of managing their roles and responsibility in the relationship like any relationship, it will fail and project overloading is just one of the symptoms of this failure. Now in the advance of the cloud or Shadow IT. The relationship gets even more complex as If IT says no the business could proceed to the cloud with its many issues and complexity
- Business management issue that starts with the budgeting process. Major initiatives may not get budgeted effectively. Or the budget doesn’t be aligned with the organizations' key result areas. This is in large part what a CIO is supposed to do, make sure expectations for IT are both clearly defined and resourced. Then, when an unplanned major new project comes along, as it will, you can state simply that it is not in the plan, and that whoever is asking needs to work with you to acquire the resources needed for this unbudgeted project.
- Misalignment with the lack of strategic governance, few organizations systematically monitor alignment of project demand to prioritize business initiative. Projects should be scored with alignment carrying a large factoring influence. In addition, corporate performance and metrics should be aligned to this same strategic prioritization. Too many functional turf wars are really the result of disparate or even conflicting goals and objectives at the senior leadership level.
- Using traditional, "Push," or Plan Driven Project Management Methodologies for software development or software implementations! Yes, the methodology is "easier" to understand and use; but it DOES NOT WORK in many circumstances, especially to adapt the fast pace changes facing in business today.
- More often IT takes the wrap for projects that have been delivered but never operationalized. This is not an IT problem. Ownership resides with the businesses. Add to this the ability for the businesses themselves to absorb the change
2. The Solutions to Fixing IT Project Overload
1) The level at which the prioritization process is owned becomes critical. It is usually necessary to kick decisions up to the executive level. IT dollars are a corporate asset. It is the executive's job to prioritize projects that support the business and they have the power to allocate the resources necessary to accomplish the myriad needs in today's business environment. There is a chain of command/authority for a reason. Use it strategically. There needs to be a well-defined project portfolio prioritization and governance process with business partners. Further, it should be a continuous process of re-evaluation. When a new initiative comes up, the senior stakeholders must be able to move something else to the bottom of the list. At times throwing resources at initiatives stops being effective. Some projects truly can wait but every stakeholder wants what they want when they want it. Ideally, the CIO has a seat at the Board level or, at least, access to Board members and can articulate what can and cannot be achieved during the year. What cannot be achieved must be explained
2) Ensure the business is the key part of prioritizing the work, whether that be an informal Top 10 list or a more formal Steering Committee. And those other managers might show empathy to IT challenges when they come with their list of "nice to have " projects. It can take quite some time to introduce into an organization but is well worth the effort in a developing a long-term partnership with your business users to help you prioritize their demands. Get them all in the same room. An annual planning meeting coinciding with your capital planning process is good. If their "must have" demands exceed your department's capacity or capability then ask them to justify the additional resources you will need to complete their work
3) Say “No” with Reasons. The first as you have identified is the ability to: "Just say NO," establish credibility with other managers and executives so that when you say "no" or "later" to a
project they know you are making your decision based upon facts and analysis rather than fatigue
and chaos. You don't have to say no, you can say yes to a condition. The mechanism can be
used such as: Charging back the department requesting the project for resources needed and
requiring a written request with justification are two good ways to curb "Project Overload", though
not a panacea.
project they know you are making your decision based upon facts and analysis rather than fatigue
and chaos. You don't have to say no, you can say yes to a condition. The mechanism can be
used such as: Charging back the department requesting the project for resources needed and
requiring a written request with justification are two good ways to curb "Project Overload", though
not a panacea.
4) PPM and prioritization component within IT as well as in the other business areas since all business projects, IT or otherwise, originate typically with a sponsor. Capacity or capability has to be taken into consideration as business plans for projects are developed and put forward. The additional capacity requirement for both the project itself and post-implementation ongoing maintenance should all be factors in the business plan; The portfolio management process itself is a governance process which is usually tailored to match the organization’s type of business, culture and company size. Further, how to take advantage of the latest technology/management tools may also help a lot, such as an effective PPM tool/scoreboard, or smart project analytics tools.
5) Work with your team to prioritize work methodically so that staff understands why they are being asked to work late on certain projects, and why they are not getting to work on their own "pet" projects. Listen to them when they tell you they are overworked. Learn to cancel bad projects without blame or regret. Move on.. Based on the resources you have known where your cutoff is in terms of how much you can work on, at any given time. Then have fight for additional budget and resources, to work on additional projects above and beyond your normal capacity. Weigh the projects, look at cost/savings metrics, resources, schedules, benefits, etc
6) Using an Agile methodology & Agile Project Management tool forces the business to be involved in the process - and thus more willing to partner with you. Using Agile really help alleviate frustration between team and management due to a strong communications channel around status, progress, burn rates, challenges, etc. And by delivering small releases in shorter increments, allows the business to make use of the new enhancements / features earlier. Plus, if a project should not be done, it allows you to kill the project earlier - and thus, you don't waste precious resources on something you shouldn't be working on. And Agile methodologies typically have a huge improvement in team morale and productivity - and the effects are very measurable.
<7) Governance around the project portfolio. It is more than business involvement in the prioritization that is needed, it is "business" ownership of that process. IT is part of the business and IT projects should be held to the same justification, approval, and prioritization process as any project. That said, this can only happen when the business at the highest levels "owns" that process. The governance body such as Steering Committee are composed of the heads of each line of business and the CIO, project approval, budgeting, and prioritization are their responsibilities. Each business case sponsor would have to make their case to the committee. The committee collectively prioritizes the portfolio and makes adjustments. Risk assessment with a proper cost-benefit analysis will give a clearer picture of what a project is worth to an organization. It's far easier to argue to kill a project if the lines in the sand are drawn earlier and in a more rational state of mind than mid-project when so much effort has been invested. Nobody wants to be the first one around a table to declare a project a failure or half-a-success, but if risk analysis and cost-benefits are done properly, you can, at least, come away with a set of lessons learned and reassign the resources quickly.
8) Requiring an ROI for each Project - for the vast overwhelming majority of IT projects, conducting a formal ROI analysis is typically a waste of time. Most of the projects have soft dollar / productivity impacts that can be difficult to estimate and measure after that fact. Plus even if you show staff reductions, most CFO's know that this probably won't happen or won't happen to the extent you or the business sponsor suggest. It is easy to claim a certain ROI before the project starts - much more difficult to actually measure the results after the fact. It is usually better to have the business sponsor to simply lay out a bullet point list of the benefits of the project and have them pitch the project during your steering committee or other executive review & prioritization meeting.
9) Demand/Supply management. It is critical to balance the demand vs. supply relation. Establishing a predictive model for resource needs based on the project pipeline and maintaining a lean supply chain is crucial too. On the "capacity" side of the equation, the technology senior team needs to be united in their focus on maintaining an effective (granular, project by project, name by name, % allocation, etc..) in project tool repository. There then needs to be a resource planning "process wrapper" around the continuous reviewing of the resource gaps, risks they pose and the potential resolutions. There are two fronts to watch: managing infinite requests for finite resources and anticipating those requests. An organization needs to make sure that enough resources are available to deliver the programs and projects, also manage the interdependencies of the project via enterprise architecture framework.
10) Talent Management: few organizations know and are true to core competencies, for an organization thinks it does everything equally well though it really doesn't have the starting or role player depth to pull it off, projects slide into oblivion and rarely deliver the intended benefit even when complete. External resource talent must be a part of the capacity equation and IT leaders must be willing to come to grips with the talent that must be sourced and the correct model under which to do so. And, whether internally or externally sourced, not only projects but individual performance must be measured against the strategic prioritization.
In conclusion, the art of management is achieving goals despite limitations. So the right approach to solve “IT overloading” is to prioritize projects based on strategy and provides a mechanism to move resources to key projects at the cost of slowing down or even closing some other non-core projects, to ensure IT manage the right projects and become the true strategic differentiator for high-performance businesses.
1 comments:
Thanks for sharing this Agile Project Management Tool! Looking forward to discovering how it can enhance our team's workflow.
Post a Comment