Analysis of why a custom software development project failed often attributes responsibility to terminal stages of the project: poor testing, delays, poor user experience design, etc. This is like attributing the taste of a pie to the server who brings the plate. In reality, the causes of software project plan management woes occur earlier in the software project lifecycle and, thankfully, are easier to remediate. Then again, we wouldn’t be worried about them if they were easy to avoid.
Herein, we highlight four key factors that set a software project plan on a course toward eventual success… or doom it to almost certain failure. Controlling for these factors in the first few weeks of a project can pay enormous dividends in the end.
A software project plan has a timeframe, a budget, and the desired scope (the set of features and capabilities the software will have when the project is “done”).
The features that make up the scope are not all equally critical.
There is also an optimal build order for the scope items that: a) reduces risk, and b) reduces effort (time and cost). There may also be other external dependencies that need to be taken into account.
Have regular, intelligent discussions about the project with all stakeholders;
Re-prioritize the work if and as assumptions and business realities change;
Identify potential interim releases that can bring business value sooner, and thus:
add to the trust between all parties, and
give the development team early user feedback that can be incorporated into further development along the roadmap.
Scope is often thought of as features you can see and manipulate. Often overlooked is the critical “adoptability” feature which drives how easily and willingly users will engage with the new software, and how productive they will be when they do engage.
The way to achieve high adoptability (and thus realize the best return on the software investment) is to include user experience design in the work of the software project plan. This means conducting:
User research to engage with users early on and understand their needs and aspirations. Note that this often yields insights that can radically improve the product, or at the very least impact scope priorities.
Professional user experience design to ensure the application’s navigation, readability, and transactional features as well as its aesthetic, which encourages adoption.
Usability testing to run the actual application (as work in progress) past actual end-users to get their feedback, incorporate it into the roadmap, and adapt the software to address users’ feedback (if needed) before the actual launch.
There is a golden triangle in software development: time, money and scope. At least one of these must remain flexible until the project goes live. If you can’t build a consensus with all stakeholders as to what that area of flexibility will be, chances are the folks who write the checks are thinking that they will get a fixed-price, fixed-time, fixed-scope project. We call that a 3F project and at some point, either at the end or maybe before the end of the software project plan, that kind of project is going to get a grade of F (i.e., will fail) on at least one of those dimensions.
How does DOOR3 stay out of the 3F trap? We watch for it, we know it when we see it, and we fight against it. If necessary, we’ll walk away from a project if all of the stakeholders cannot agree on at least one area of flexibility. We’re explicit about it. Too often, other software specialists will provide all the information business stakeholders need, but only in vague ways. So in return, they get only a vague commitment to be flexible. Then what happens when deadlines begin to loom? Those vague commitments are forgotten and the 3F pressure comes back with a vengeance.
And that brings us to our last point.
Openness, transparency and trust are essential for successful software project plans where key stakeholders don’t have the knowledge to personally verify what technical staff say.
That makes it even more essential to ensure rapport between all project stakeholders.
If you’re the technical stakeholder, be transparent about challenges your team faces with time, resources and scope.
If you’re the business stakeholder, share your fears, uncertainties and aspirations for the project.
At DOOR3, we negotiate realistic outcomes with our clients. There’s no amount of money that can make a software project plan go faster than its maximum speed (adding people does not work beyond a point). There’s no amount of tech talk that can change a deadline driven by (for example) a critical conference with a fixed presentation date. But there’s usually some give and take available, if the rapport and trust between parties is strong.
In summary, a successful project is all about risk management** **choices: the choices you make at the beginning as you develop your roadmap, the choices you make along the way as you negotiate against the 3F trap, and the choices you make in identifying and fostering the human relationships that make all the other choices possible.
DOOR3 creates digital solutions that empower users, engage consumers, elevate brands, and enhance businesses. We have extensive experience crafting custom business software solutions that succeed on every level. We can do the same for you.
We would love to hear about your reactions and your experiences, and perhaps find a way to partner together toward another successful software project plan launch. Contact us today!
The Migration of legacy systems may seem straightforward in concept, take information in an older system and put it in a newer one. The process of doing this however, is...
We are pleased to announce DOOR3 has received The Web Excellence Award in App and Mobile / Sustainability for our work with Retrievr UX mobile development. The Web Excellence Awards’...
The list of legacy system migration challenges for enterprises is extensive, as migrations can be a complex and challenging process, with many potential roadblocks and pitfalls along the way. For...