Tag: Plan

5 SDLC Project Management Pitfalls and how to Avoid Them

Written by Cassandra Naji on July 27, 2016. Posted in Articles. 2 Comments on 5 SDLC Project Management Pitfalls and how to Avoid Them

Avoiding these 5 common pitfalls will make your next software development project more agile and cost-effective, and will result in a better product.

Successfully pulling off a project can be challenging at the best of times, and when you add tricky software development into the mix things can get a little out of control. Pitfalls pop up unannounced, from correctly time-scoping development stages to latent stakeholder lethargy. While it’s all too easy for project managers to fall foul of these 5 common problems in the software development life cycle, getting a handle on pain points can help improve management practices and streamline any future software development undertakings. Ultimately, a pain and problem free project results in lower costs, a better product and fewer headaches for the project team.

1 – Planning timeframes

A well-planned schedule is one of the keystones of a successful software development project. And while PM tools are great, even the most sophisticated tool won’t save you from unexpected glitches. Smoothing the way for the development team requires canny prioritization, clear values, and an ability to predict the true impact of team actions.

Related Article: Avoiding Top Project Pitfalls

When planning SDLC timeframes, create a detailed task list: you can find templates that will help you organize all the smaller activities needed to bring to fruition a larger goal. Writing down all the steps required to meet a target ensures that a) fewer steps are overlooked and b) each step is less likely to be under-estimated in terms of time taken to completion. Also, if a deadline starts to creep up on you, a detailed task list will help you redefine the scope: you can either adjust the schedule, reduce the number of things you were going to do, or add resources.

With a task list, nasty surprises are less likely to crop up mid-development, and it will be easier to see at a glance where you can add or pull resources or activities without negatively impacting coding.

2 – Prototyping too infrequently

Early-stage prototyping and mid-stage iterating are vital to smooth project progress, especially in agile development methodologies. Running through the full family of prototypes will iron out potential pain points without increasing spend: use paper wireframes on user testers in initial stages to work out IA; present clickable mockups when explaining the idea to the development team; build a high fidelity prototypes when you’re nearing the final stages and need to convey the highest fidelity to clients or stakeholders.

3 – Failing to anticipate problems

There’s one big reason why Project Managers don’t spend enough time planning for problems. Because they don’t want them to happen! Sadly the ostrich technique isn’t so effective. A better strategy is risk management. Risk management can be done visually in a work flowchart, which is then checked against resource conflicts and component dependencies. Once identified, you can plan around these potential problems – lengthening lead-ups, prioritizing certain pathways and freeing up resources just in case. Building pauses into the SDLC around these potential obstacles can be a great point to build in mid-cycle quality testing.

4 – Failing to allocate tasks properly

Software development is a competitive field, and sometimes everyone wants to be the hero. But ‘heroics culture’ – pulling 20-hour shifts and moving heaven and earth to get the project done – can ruin a project. Isn’t it better to be organized and obviate the need for heroics in the first place? Creating a realistic schedule in which activities and responsibilities and wisely allocated is the best approach. For example, if you’re at the coding stage, let the developers know what tasks they’ll receive through the API and the results you expect to see in their code. Then leave them alone.

In terms of team organization, be wary of putting one person onto two projects and expecting equal investment in both, and make sure you’re providing enough staff and support for each team.

5 – Failing to engage stakeholders

Even the best PM can struggle when faced with difficult or disinterested stakeholders. Trying to keep stakeholders happy and still respect scope and spend can seem impossible. If you’re managing requirements within the project, try keeping stakeholders engaged by swapping out text-heavy requirements documentation for more streamlined tech such as a prototyping tool. Within this, you can add stakeholders as a user and have them collaborate on requirements, and everyone has access to the version history – everything is traceable. Plus confirming implementation of each requirement within the tool will keep your stakeholders in the loop.

The Importance of Continuous Project Tracking

Written by Lawrence H. Putnam, Jr. on July 20, 2016. Posted in Articles. 5 Comments on The Importance of Continuous Project Tracking

Developing early software project estimates is an industry best practice, but creating those estimates is only half the battle when it comes to improving productivity.

By continually keeping the pulse of a project—measuring performance against estimates and adjusting when necessary

—teams can gain valuable insight into their software development processes. This insight can be leveraged in future development cycles, leading to more efficient production and a better bottom line.

Estimates are just the beginning. Project tracking, reforecasting, and post project review are three valuable strategies teams can employ to monitor the development process and improve outcomes.

Strategy #1: Project Tracking

Current popular methodologies, like agile, promote metrics tracking, specifically with respect to size and velocity. But all developers, agile and otherwise, should take care to ensure that they’re tracking the correct metrics, which can include:

Cumulative size produced: this can include source lines of code, agile stories, screens and so forth;
Monthly effort: the number of person months or person hours spent;
Staff: the number of full-time equivalents billing time to the project; and
Defects: how many errors are discovered.

Data can be collected weekly or monthly, depending on the project’s schedule, and, to gain the most insight, should be compared with the project’s original estimates. Then, teams should try to figure out why deviations from estimates are happening. Is there an imbalance between management and developers, leading to a lack of skilled employees needed to complete the project? Has the team introduced new tools, methods, or team members? It can take time to ramp up on production if any of these variables have been introduced.

Strategy #2: Reforecasting

Software development cycles are rarely executed exactly to plan. Team members may have been pulled away to other projects, a large number of errors may have been found, or other variables may have been introduced. Any one of these situations will cause a deviation from a project’s original estimate. When teams examine metrics and notice that deviations are happening, it is best to reforecast, or re-estimate the project.

Certain project management tools use metrics to automatically recalculate project roadmaps. These tools can give new forecasts based on the data the team provides. It is certainly more advantageous to correct deviations early, rather than waiting until the end of a development cycle and risk missed project commitments.

Whether teams use prepackaged tools or their own estimation techniques, they should inform stakeholders of revised project plans as they develop. Reforecasting provides a window into the project’s progress at regular intervals. As more data is collected and forecasts are continually refined and communicated, project transparency and accountability also improve.

Strategy #3: Post Project Review

When a project is finally finished, teams are usually ready to power down, close the books, and take a break before diving into the next big thing. The project’s level of success is often perceived as somewhat irrelevant—team members usually want to move on quickly.

However, taking time to do a post-project assessment is a great strategy to continuously improve team outcomes. Just like project tracking and re-estimating, post-project assessments provide the opportunity for a collective pulse taking.

In its most basic form, a post project review gives team members a chance to evaluate what went well and what could be improved upon for the next project. Post-project assessments also give teams chances to assemble final sets of metrics that, when examined with data previously collected on the project, may provide more accurate estimates for projects going forward.

The Bottom Line: A Better Production Cycle

Strategies such as project tracking, reforecasting, and post-project assessment all help team members refine project estimates on the fly. When updated estimates are shared with stakeholders, communication among project team members and accountability are improved.

Over time, the process of collecting data, updating trends, and using trends to estimate future projects creates a circular process that creates more refined estimations over time and across multiple project cycles. More accurate estimates can translate into happier stakeholders, a more judicious use of resources and, ultimately, a better bottom line.