Practical Technology

Having trouble getting your project done on time and under budget? You’re not alone. Experienced project managers share suggestions about getting the work done without losing your mind.

Frederick Brooks’ classic book, The Mythical Man-Month, tells the tale of how everything that could go wrong did go wrong with the development of the IBM System/360 computer family. He walked away from the experience with realizations about the core problems with traditional project management. More than 40 years later, we are still trying to solve them.

How many of these issues plague the projects you’ve been involved with? Brooks wrote: “More software projects have gone awry for lack of calendar time than for all other causes combined.” Then there’s the “unvoiced assumption which is quite untrue, i.e., that all will go well.” Or, “Our estimating techniques fallaciously confuse effort with progress;” and, last, but never least, “When schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse.”

While project hiccups and failures are always a danger, in the intervening years the business community has learned to avoid many of them. Fortunately, we have found ways to deal with these fundamental problems. One of them is sharing information about what works and what doesn’t – as these experienced project managers do here.

Know what you’re trying to accomplish.

First and foremost, you need to know what you’re actually trying to do with your project. “Consistently ask this one question: ‘Whom are we targeting with this project and what problems are we solving for them?’” says Spencer X. Smith, former VP of sales at a Fortune 100 company turned consultant “This may sound obvious, but oftentimes—especially after a project has been underway for a while—we neglect whom we’re trying to serve.”

Once you know not just what you’re trying to do, but whom you’re doing for, you’ll be a lot better off.

Avoid scope creep.

Kenneth Ashe, PMP and project manager at Prudential Financial, suggests that an important way to make projects finish on time and within budget is to avoid scope creep. “Scope creep is added changes that can occur once the project already started (an increase in project scope),” Ashe explains. “If you don’t consciously look for and prevent scope creep, it’s easy for projects to grow in size and blow through timelines and budgets.”

To avoid scope creep, says Ashe, “Create a well-defined scope at the start of a project that the project’s sponsor and/or customer formally approved (a signed document). Any additional items that are requested outside of the original scope would be considered a change to the project, and their impact to the entire project must be considered. You should assess how these changes will affect the timeline, costs, quality, and resources assigned to the project.”

That’s easy to say. It’s not so easy to do. Especially since few project managers define the project well in the first place, says Kevin Archbold, PMP and consulting manager of Key Consulting. “This is normally done using a project charter. I consider this like putting the first tile in place in a tile floor: Mess the first one up, and everything from here on will be a problem.”

Practice Agile.

Once you have a plan, and everyone’s on board with it, your focus should move to keeping the project on track. Use Agile techniques, urges says Cord Silverstein, acting VP of marketing at Samanage, a Software-as-a-Service (SaaS) company. While Agile is often used in software development projects, it can also be used in other projects.

One hallmark of Agile is project status transparency. For example, Silverstein believes that “Everything should be public: The work that needs to be done, our sprint plan, who is assigned to what, what people are working on. Transparency removes many time sucks including unnecessary meetings.”

Schedule for real-world delays.

Help your projects work well by setting an appropriate schedule for the scope of work. But keep in mind, says Larry Putnam, Jr., Co-CEO for Quantitative Software Management, “Nothing goes perfectly. Make sure you include a risk buffer for unexpected adjustments throughout project implementation to ensure you stay on time and on budget.”

Oh, is that all? A radical way to address scheduling concerns, according to Bridget Duffy, EVP of business management at the design and technology firm DUFFY, is to “kill the calendar.” Duffy deplores “that artificially concocted calendar that tells the team what time they are allotted, and doesn’t account for creativity, human interaction, or the chasing of excellence. In fact, it is the calendar itself that keeps design and development projects off track.”

“Estimating time is a crapshoot at best,” Duffy explains. “The reason is simple: Top notch designers and software developers rarely create the same thing twice. A designer may come up with the ideal design solution in half a day. Or it may take 20 times that. Or more. Or less.”

Duffy adds, “Most teams talk about being agile, but in fact stick to a ‘waterfall’ calendar that waits for one task to be complete before starting the next. Waiting is not working.”

That sounds great, but you still need to deliver your project. The answer is in teamwork, Duffy says. Create “a smart, agile team of designers and developers which is, by nature, a small, well-oiled machine.”

Scheduling is essential, says Duffy, but it is a living, breathing, moving thing. “It is not a static calendar. It is a tool to give a little structure to the people doing the work. It does not, and it never will, replace the need to really know your team, to communicate with them to avoid frustrating them with annoying reminders. The closer your teams of inside and outside members can be unified, the better your chances of being on time. And better yet, on budget.”

Focus on internal communication.

To make a team like this you need great communication. Dana LaRieal Morales, PMP and leader of The Happiness Bucket, an organization meant to help people move through life changes, believe you must “Determine how the project team is going to relay information to one another, so no matter who was or wasn’t in a meeting, everyone on the team can go to one point of reference to get caught up.” Use an Excel spreadsheet, wiki, intranet site, etc.: whatever works. “Whatever it is, I would suggest it be something that multiple people can access at the same time. Steer away from email/document-based updates whenever possible, because these often remain unread,” says Morales.

Frequent communication doesn’t mean lots of time spent in a conference room. “Meetings are the enemy,” says Duffy. “Clearly-defined roles make the difference. This, of course, requires knowing the people on the team. This is where generic staffing or outsourcing falls short. You can’t communicate with a revolving door.”

Morales also believes that you must keep your customers in the loop. She says, “Whenever appropriate and possible, create moments where you can show a completed part of your project. This could be the sandbox environment (the system with dummy data) or even a screenshot of the intended environment.” Doing so lets clients or users provide feedback on the project’s direction, and identify areas of concern.

“You can either resolve the concerns in the project itself or manage expectations,” Morales adds. These “moments” help eliminate project tension caused by mistrust or by individuals feeling like they aren’t heard. “By adding these tips it allows for on-demand participation without derailing the project or the team meetings.”

And isn’t reducing tension going to go a long way towards making any project go better, both for the people on the project team and for its stakeholders? I think so.

Will these bits of advice solve all your troubles? Heck no! But it’s amazing how much a little effort in the beginning can prevent big problems from appearing in the end.

5 Project Management Fundamentals Learned the Hard Way (So You Don’t Have To) was originally published in CertWise.