Improve development project focus with these member tips

If a software development project goes awry or astray, your department may have a lot of explaining to do to customers or the accounting department. Read ahead to find out what some members recommend to keep projects on track and in focus.

Admitting defeat is rarely pleasant. It’s particularly harrowing when failure comes in the form of a development project gone wrong—especially if there are anxious customers counting the days until the date of delivery.

While there’s no surefire way to ensure that projects stay on track, there are warning signs that discerning management teams should consider. In his recent article “When good software projects go bad: Three telltale signs,” TechRepublic columnist Tim Landgrave outlined the top three reasons why development projects go awry. Based on comments in response to the article, TechRepublic members have their own ideas about factors that can make or break projects. This article highlights some of these member opinions.

Aligning business and tech perspectives
When people from business development or sales dictate the requirements for a project, there’s often a risk of poorly defined or unreasonable expectations from people too far removed from the tech side of development projects. TechRepublic member webmaster calls this a “clash between strategy and reality” and believes that it's one of the most damaging characteristics of many projects.

“After the initial ‘how-do-you-do’ and ‘this is what I want,'” wrote webmaster, “they’re [executives] never seen again….In the end, no one knows exactly what the heck was intended.”

Incongruent business and tech expectations not only impede the progress of a project, but they can also negatively impact a development project after completion. Kim Kelly believes that business management’s attitude and interest towards a project are important during development but are most crucial after a project has been implemented into the enterprise.

“Without business management’s unwavering support, software projects easily fail, either through a lack of support during development or lack of commitment to what the system can achieve postimplementation.”

When management begins to develop and document policies and procedures for the project, only then do they truly demonstrate their understanding and support of the undertaking. Without this verification of support from the business side of the project, Kelly believes that the potential for failure is immense.

Steady exchanges of ideas
Part of ensuring business development and management cooperation rests entirely on solid communication among all involved. Business representatives, developers, project managers, customers, and whoever else is involved in the project have the responsibility of making sure that their own ideas and concerns are apparent to everyone else. However, according to TechRepublic member Isabel Burkholder, the project manager may need to facilitate communication if other people are reluctant to ask questions on their own.

“Questions that lead people…are crucial to overall success. This applies to clients as well as developers. The worst thing that can happen on a project is everyone goes back to their corner and develops in isolation without addressing issues.”

Cyber Cowboy’s organization values communication enough to seek input from its customers on projects within the company. Currently, the company is working on an internal database implementation for its Operations Department. Whenever a tech meeting is scheduled, Cyber Cowboy invites customers to attend and comment on the project.

“If they cannot come, then we send our developers out to them,” wrote Cowboy. “They look at how the customers use our product and bring back the notes for our team’s full discussion. So far? It seems to be working.”

Resource matters
When there’s a shift in project demands, chances are good that there will be an accompanying change in the resources necessary to carry out the project. Too often, project changes are considered without a clear understanding of the finances or labor hours involved with a change.

For example, Norman Long once knew a project manager who kept a sign above his desk that read: “Scope/Resources = Time.” Whenever a team member came to the manager with the intentions of changing something about the project, the man insisted that the person explain how he or she would make up for the increased costs or workload. According to Long, considerations like these often kept projects on track because they discouraged “the business side” from making noncritical changes that would eventually delay the project.

How do you keep projects on track?
Do you have any tips for meeting project deadlines? Are there other common pitfalls that signify pending project delays? Join the discussion and share your thoughts.


Editor's Picks

Free Newsletters, In your Inbox