For many IT organizations, creative project management solutions remain a significant challenge -- and the lack of them leads to implementation delays, incorrect functioning, blown
Two stages of the project management lifecycle are often overlooked or rushed through, but if organizations were able to get them right, many more projects would succeed. The secrets of creative project management are prioritization and cross-functional project teams.
Before you can even start gathering business requirements, your project needs to be assigned the right priority. If your organization is experiencing major problems with IT projects, look at the way you prioritize them, and examine what might be going wrong. Project portfolio management is an area that that is rife with potential trouble spots. In many cases, projects get prioritized based on political infighting or power struggles, rather than on decisions about which improvements are right for the business.
Creative project management based on IT, business requirements
When cross-functional teams don't understand a project well or when ongoing workloads are not taken into account when a long-term project is being planned, project management solutions are destined for failure. In most places, the same project teams that will implement a new initiative also are responsible for the day-to-day operations workload. That workload has to be considered when the amount of time needed for a project is being estimated. When timelines are estimated incorrectly, projects are doomed to fail before they start.
In addition to juggling your team's workload, you must involve senior leadership, at least at the beginning. Without a project governance structure that has broad leadership buy-in, you'll never get through the political infighting that naturally comes when scarce IT project resources are being assigned to a project team. Personally, I believe that project resources should be managed just as organizational finances are -- both are used to serve business goals, so they should be treated similarly.
I've seen firsthand the results of what happens when prioritization isn't based on business goals but on political infighting. The problem: Everyone knows it's taking place, and other executives get frustrated. That leads to constant angst in the organization. Further, the IT group can't be effective when scarce, critical IT resources aren't used appropriately. This also leads to project management priorities being reshuffled constantly -- a spiraling effect that leads to IT staff burnout and stress.
Core, cross-functional teams necessary for successful IT projects
The second area that needs more attention is the initial business requirements-gathering phase. Once an IT project has had a rigorous review and its implementation has received a green light, the project team should gather the business requirements and match them against business goals and outcomes.
Resist wish lists in business requirements gathering
After you've appropriately prioritized your project and gotten your ideal core team in place, it's time to begin business requirements gathering. It's essential that you get input from everyone with any kind of stake in the project, whether they are part of your core team or extended team, or are end users or executive team members.
Your stakeholders might want to turn this conversation into a "wish list" discussion. Resist this push, and help them focus on the business objectives for the project. Wish-list items are nice, but if they don't meet a project goal, all they do is add to the project scope and increase the risk that the project will fail to deliver.
The biggest factor determining whether a project will succeed is the composition of the project team. The right mix of people will help you achieve all of the goals set forth in the initial project charter. Get the wrong people involved, and your project is doomed.
When I manage projects, I like to take a two-tiered approach to creating project teams: I use core teams and extended, or cross-functional, teams. The core team's members should be stakeholders in the project's outcome. They also should have some kind of day-to-day responsibility for the business work that the project encompasses. Ideally, the core team should have both a business lead and a technology lead.
The core team's business lead needs to understand the target process inside and out. This is not negotiable. Too often, project teams don't understand the full scope of the effort and items are forgotten or are misunderstood. Ultimately they are implemented incorrectly -- or not implemented at all. A single individual can be both business lead and technology lead, as long he's extremely well-versed in both the business requirements and the technology. This one-person approach is often used in smaller organizations.
Extended, cross-functional teams comprise anyone playing even an ancillary role in the project. Such teams will meet less often, generally only as needed. For example, at a college implementing a new fundraising system, the fundraising staff might be on the core team while the general finance staff might be on the extended team. Finance staff people would be brought into the picture when there is overlap between functions and when integration points need to be discussed.
More about creative project management
Unless it's necessary, the extended team shouldn't be included in the core team's meetings. I've seen great discussions truly derailed by non-issues because the wrong people were on the core team. This doesn't mean that certain details should be hidden from people. It does mean that project teams need to be agile and team members need to understand the business.
I believe that solving problems with creative project management and perfecting a project's early stages -- gathering business requirements and selecting an extended team -- will avert most project issues that today's IT organizations face.
Scott Lowe is the founder and managing consultant of the 1610 Group. A former CIO, he's a frequent contributor to TechTarget, TechRepublic and other IT publications. Write to him at email@example.com or firstname.lastname@example.org, or follow him on Twitter @OtherScottLowe.
This was first published in April 2012