Delivering software projects on time and on budget can be a tough task.
Delays, scope changes, and scope creep can impact not just the timeline but the final return on investment as well.
If you are a product manager you know what i am talking about:
You do everything in your power to control the dependencies of a project. You try to get alignment from all stakeholders. You obsess over the details and the big picture....
And somehow, more often than not, something goes wrong.
A deliverable gets delayed. A stakeholder tells you “This was not how I expected [insert feature here] to work!” Or, no matter how much you try to communicate clearly with your IT team, a developer gets it just wrong enough.
Software development often ends up being the victim of the domino effect. Just one piece falls and everything that comes after it is affected.
So why does this scenario play out in seemingly every major development project? Why does the product manager always get trapped in the middle?
In this article, I’ll discuss 9 common factors that I think cause these issues. It’s an attempt to make sense of the chaos - to help reduce risk and empower teams to work smarter and faster.
And although these tips may not solve every issue, I strongly believe that these actionable solutions can get you closer to delivering the right software, on time and on budget.
Let’s get started...
Successful software development teams have clear processes in place on how to run their day-to-day work. They also have managers who allow them to work around those processes when team members identify ways to speed up a project.
In order to deliver a project on time, companies should focus on providing just enough guidance and “law and order” for teams to do well at their jobs and to set clear expectations.
Are you managing a large scale software development project? If so, can you check off all the process items on this list?
In this graphic you see a list of best coding practices that our developers have put together to help ensure that working software is released on time and on schedule. This is not a “one size fits all” list. Some teams may want even more process, some less. However, the idea is simple: It’s important to document how developers, analysts, managers, designers work together in a productive way, and what is expected for each individual team member.
If a team is presented with unclear and inaccurate requirements at the onset, they will estimate an inaccurate level of effort (typically measured in hours or days of development work).
As the saying goes, “garbage in, garbage out.”
There are two common issues teams face when it comes to requirement gathering: requirements clarity and stakeholder’s interpretation of the requirements. The two are interrelated, but distinct issues.
Let’s run through an example that demonstrates why...
B2B company trying to build functionality without providing clarity on the requirements
A B2B company is redesigning their e-procurement platform, which interfaces with ARIBA ecommerce. The way e-procurement works is this:
- A customer logs into Ariba
- They click on a vendor’s name
- They are redirected to the vendor’s site which is loaded in an iFrame
- On the vendor’s site, they add products to cart
- The cart is transferred to Ariba where the user completes the purchase
Last piece of information: this vendor has a site for e-procurement integration with Ariba but they also manage a direct website for other small and medium current customers. The company wants to do a complete redesign of the vendor site for this experience.
The business stakeholder provided the following requirement for the e-procurement vendor site, which interfaces with Ariba:
“As a user I would like to have access to an Order Center widget and functionality which allows the user to access their previously placed orders in the same fashion a direct user can see their orders today.”
From this simple request, there is a tremendous amount of unseen details that needs to be figured out to provide clarity to the team (including design, architecture, timeline, and how to track the overall performance/success of the feature).
From the business side, there are a lot of specific requirements that need to be flushed out in order to clearly understand how the feature will be implemented.
Where should the order center widget be shown?
Is it on the logged in dashboard only or will there also be a link in the global navigation for the Order Center?
How many orders should be shown by default on the widget before the user must navigate to another page?
What information will be shown to the customer: date the order was placed? Contents of the order? Estimated delivery date?
Should the user be able to navigate directly to the order details from the widget?
Should we give search options to that user to quickly locate a specific order?
Should orders be listed from the most recent to the oldest order?
...and these questions lead to other unforeseen questions.
Word documents and Excel sheets, sadly the tools most teams are still given, doom well intentioned business analysts and project managers to providing developers with a BRD with inaccurate and missing requirements.
Given this reality, how can a developer provide an accurate estimate for the level of effort? They’ll need to answer some of the questions themselves that the user should be answering (never a good idea, no matter how talented the developer). The word “guesstimate” comes to mind.
The simple answer: Interaction, collaboration and traceability
The best approach for providing clarity to developers and stakeholders is to create interactive, prototype driven requirements. Let them experience and test-drive the proposed functionality.
Use wireframes and prototypes, along with the ability to iterate quickly, to flush out stakeholder requirements. And let them capture requirements in stories within the screens they describe. This gives everyone proper context, something that reading text in a Word doc can’t do.
You can still create reports and documentation, but don’t let them drive your decisions.
COLLABORATION & TRACEABLITY
Silos have a tremendously negative impact on the software development process. They prevent teams from collaborating effectively. Teams to share information in real-time and communicate, but far too often they can’t.
Disparate, disconnected tools is the chief culprit.
I recently attended one of the largest business analyst conferences in the world, and I can’t tell you how many times I heard: “We use x tool, but the dev team uses y tool, and our testers use z.”
In today’s Agile world, how can this workflow succeed?
The way iRise solves these problems is by providing a platform for diagrams, wireframe and prototype-driven requirements, and by connecting all the other great tools you already use through integrations.
It’s a process that works wonders...
During a recent iRise webinar, Doug Brown, former VP Senior User Experience Designer at JPMorgan Chase and Manager of UI Engineering for eCommerce at DSW, discussed how he’s using and integrating iRise and JIRA to bring together requirements, Lean UX design, and the Agile development processes.
Using real-world examples, Doug showed how he’s dramatically improved both the design and development phases of his projects while cutting time and costs.
is worth your time if you’re experiencing similar issues.
Requirements clarity is the single biggest reason why, in our experience, the cost of software projects increase and the timeline is pushed out. Having in-depth product documentation, with all various scenarios being laid out, discussed and validated, is critical to keeping a software project on budget.
In fact, experienced product managers will often allocate 30% of the overall project plan and budget to in-depth requirements gathering, analysis and estimation. So why not give them the right tools?
At the end of the day, inaccurate requirements impact both the developers’ estimation process and the overall cost and release date of a project. Getting it right upfront is essential to estimating a software project accurately.
Learn how to differentiate between the things a stakeholder really needs to complete a task and those that you think they’ll need. The secret of creating an MVP is learning exactly what features are necessary to have a functional product (and no more).
Some companies and product managers have difficulty adjusting to a very simple reality: 45% of the features and functionalities they built are rarely or never used.
This is a staggering stat when you consider how much time, money and mindshare that 45% can take up.
Creating complex features and functionalities is, arguably, the result of a generation of waterfall software development. Waterfall is a very rigid methodology. Consisting of specific project phases which never overlap, the model requires requirements to be gathered and analyzed upfront. As soon as developers move on to the estimation phase, the scope cannot change. The software product then goes through the various stages until it is released to production. As a result, business stakeholders have adopted a mindset of proposing as much functionality as possible because once the project is done, it’s typically almost never revisited.
In contrast, in Agile software development, both managers and developers are able to adjust scope. They’re able to define a Minimum Viable Product and then make adjustments post release if need be.
In his book, The Lean Startup, Eric Ries has an excellent comparison of agile and waterfall development:
“Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.”
Given that 50% of the features are rarely used, leveraging an MVP approach is just common sense.
Let’s consider a specific example...
They have documented this list of requirements:
- User should be able to add any items to list
- User should be able to access the Lists in the Global header
- Each list should allow user to add items directly to cart
- Users should be able to create as many lists as they want
- Users should be able to rename lists
- Users should be able to email lists to each other and other users
- Users should be able to set ordering reminders
- Users should be able to order items inside a list by name/ product codes/ date added/ date last seen
The total cost of implementation based on this scope was 80,000 dollars.
The problem with this scope is that this is definitely NOT a Minimum Viable Product.
From a funnel perspective, as a user, there’s only three steps I NEED to engage with for the feature to be successful: Add items to a list; locate the list; add item from list to cart.
Everything else represents “nice to have” optimizations. Going back to the goals above, the user can accomplish each necessary step if we simply reduce the requirements from 9 to 3:
- User should be able to add any items to list
- User should be able to access the Lists in the Global header
- Each list should allow user to add items directly to cart
Given that the industry data showing that the additional 6 features proposed would be used by fewer than 3% of all users, the MVP approach in this case study was accepted and cost decreased from $80,000 dollars to $28,000.
This is a great example of the benefits of creating an MVP. It reduced scope, cut costs, and began producing revenue much sooner.
The best way to ensure the team follows an MVP approach is by constantly asking everyone: can a user accomplish the task at hand without having access to a specific functionality. If no, then the functionality makes it to the MVP list. If the answer is yes – then you add it to the “nice to have” list (more details on this below!).
The best way to help your team stay on track is by understanding the type of guidance they need and when they need it.
Validate requirements. Over communicate with stakeholders. Review comps and wireframes. There’s no such thing as too much communication when you’re in charge of a big project!
Sometimes, scope changes are needed and justified. Through user testing or a shift in business strategy, the team may agree that the original set of requirements must be altered to achieve the desired business goals.
And then there is scope creep. Scope creep refers to unscheduled changes in the project plan driven by:
- Incomplete requirements (see issue number one in this article)
- Expansion of requirements in scope and breadth (number 2 issue above)
- The business stakeholder deciding to go in a completely different direction
How do you prevent mid-flight changes and a change of heart? You focus on what you can actually control.
When writing business requirements, you should be as inclusive as possible and engage every potential stakeholder. Using the right collaboration tools here is critical in doing it right.
Another key strategy in avoiding scope creep is accurately validating your requirements. Users often don't know what they want until they see and interact with it. That's where using prototyping and in-context documented requirements proves to be a very powerful technique to get everyone on the same page.
When product managers use prototyping tools to visualize the implementation of business requirements, internal stakeholders can "test-drive" the requirements. They can interact with a working mockup or prototype, give feedback directly on the screens they describe, while accurately validating that they business requirements are met.
Integrating all the tools in your SDLC, including a requirements and prototyping tool, also a key ingredient. This allows everyone on the team to give valuable feedback in real-time, so nothing is missed.
You must also invest your energy into communicating early and often about the project plan, the scope, and the overall progress. If you’re dealing with difficult stakeholders who frequently change their mind, making them aware of the project goals will help keep them focused on the bigger picture.
These methods won’t necessarily help you out of every potential scope creep out there, but they’ll reduce the risk of it happening substantially.
Be your own project manager. Learn how to mediate dependencies. Track deliverables and highlight risk.
There are very few projects which are within the full control of the product team. Product managers often must work closely with stakeholders for both creating requirements AND implementing them.
There is often a discrepancy between when the development team thinks they can implement a feature and when they can actually get everything they need to make it happen.
At every stage of a project, regardless of the methodology used (waterfall vs agile), there are multiple things in motion. Delivering each of them on time makes the project run smoothly. Which of course doesn’t always happen.
For example, a developer might not be able to start their work until they get final sign off from the UX team. The UX team won’t sign off and finalize their work until there’s final alignment on the wireframe. The wireframe isn’t complete until all stakeholders are aligned on the final functionality.
In software development, any delay has a domino effect on the overall development schedule and it impacts the project cost.
The best way to deal with this problem is by assigning a program manager to the software project. This is especially important when deliverables from various teams are needed. Program managers keep a bird’s eye view on the overall health of the project. They track deliverables, highlight risk, provide daily or weekly reports on progress. They are the watchdogs of a project.
This is what a project manager can do to ensure that there’s cross functional alignment across the company for a specific project:
Most importantly, program managers usually work independent of the core team and outside the influence of the product manager, designers, developers or analysts. That puts program managers in a position of authority and impartiality which is really critical to keeping a project on time and on budget.
Learn how to manage your resources effectively versus looking at staff augmentation. It pays off in the end and the return on investment is greater.
So a project is at risk of not making a deadline? Or the release date communicated by a product manager is not in line with that what the stakeholders expected. The first instinct many business stakeholders have is to suggest adding more people to the team to make the date. They should accept the revised date because most dates are fictitious anyway, but that’s a different story!
Here’s the simple reality: adding more developers to the team for a specific project is rarely a good idea.
At the planning stage, the scrum master, development team and the product manager discuss the priority of the project in relation to all other items in the backlog. They decide on the optimal amount of resources needed for any given project.
So why it doesn’t make sense to throw more developers at a code?
First, many developers on a team have very specialized skills. Once on the project they’re often assigned areas of responsibility in which they become the subject matter experts.
Throwing more developers into the mix is the equivalent to asking a second chef to start stirring the same soup, hoping the primary chef can finish the soup faster.
In general, the best strategy is to keep developers accountable by turning them into subject matter experts. If additional help is really needed, get a developer who can pick up on work from the subject matter expert, regardless of the knowledge tied to a specific project. The goal should be to free up the subject matter expert from some work and let them focus on the high value development work.
Second, more often than not, when resources are added to a project, they come from a different part of the company or from the outside (read, they work on something else) and as such their onboarding will be costly and their output not at the same velocity as the rest of the team.
Of course, for very small teams, adding more bodies may actually make a difference. There are projects when more resources are simply the only way to execute on the vision but executives should think twice before making the call.
For most projects, simply pushing out the release date to a time when the existing team can complete the work is the most efficient and cost effective strategy.
When it comes to the overall cost of software development, setting the priority of the features that are being built is of critical importance. Learn how to do it right.
When writing requirements, creating wireframe and building software, the entire team must get aligned behind a series of commonly agreed to priorities. With the rise in popularity of the Agile methodology, a new system of ranking priorities is slowly but surely gaining legitimacy and popular adoption.
It’s called the MoSCoW system of ranking priorities. The acronym stands for the following values which every component of software development can be prioritized by:
Must Have: Without these functionalities, the Minimum Viable Product requirements won’t be met. Must Have Requirements are the absolutely mandatory requirements that must be satisfied before a functionality is released to production.
Should Have: These requirements are important, but not mission critical. From a product or UX point of view, these features should make the cut but if they don’t the user can still complete a task at hand
Could Have: This refers to functionalities that are “cool” and “hip” but are not really essential to the overall success of a project. Think of minor optimizations and low hanging fruit issues.
Won’t Have At This Time: A series of features that the team decides not to implement. These features may have tangential connection to the project being built but not directly related to it. *Also known as “out of scope” requirements, the primary reason of documenting “Won’t have” requirements is to make sure everyone on the team knows that the team will absolutely not implement them as part of the project.
For more details on the MoSCoW process, we recommend reading the Handbook on MoSCoW Prioritization by the Agile Business Consortium.
When it comes to the overall cost of software development, setting the priority of the features that are being built is of critical importance. A lot of energy and effort is spent on getting alignment on the overall scope of a project. It’s not unusual for large projects to require stakeholder meetings with 10-30 people. Think how expensive these meetings can really be? Managers, directors, vice presidents, developers, designers, analysts and everyone in between coming together, often 3-5 times. In this context, it is absolutely essential for everyone to have the same definition of priorities and to weigh in accordingly so that the final requirements documented are in line with stakeholders’ expectations.
Additionally, the development team needs to fully understand what is the definition of must have requirements. That in turn impacts how they provide estimates, how they think about the solution and in what order they start building the final software product.
Product managers should take the time and explain how the MoSCoW system works (or something equivalent).
Make sure everyone subscribes to the same definition.
Review each requirement and discuss its merits based on the prioritization scale established (See the section on MVP)
Rank all requirements based on this definition and present the final list to the entire team.
When requirements are clearly organized, development teams often do MORE in LESS time. This happens because when the absolutely mandatory features are clearly defined, developers know when the MVP scope is completed.
At the end of the day, the key to a keeping a project on time and on budget is close collaboration. The tools used in everyday interactions are critical to achieving effective collaboration and communication among team members.
In order for a software development team to run optimally, teams need both the right collaboration tools and a clearly defined process in place.
As many technology companies are shifting or Agile, we will focus on refining that process. It's true that "100% Agile” is more of an aspiration than reality, but the recommendations below also support a approach.
The goal of every product manager should be to integrate all teams in the software development lifecycle. This includes ensuring that all essential resources attend the right meetings, and that the entire team uses the same set of productivity tools to effectively communicate with each other.
First you need to enforce the typical “agile ceremonies.”
They are in place because they have been proven to work well for a team. Attendance to the daily standup, bi-weekly iteration planning meetings, mid-sprint checkpoints, retrospectives, and scrum of scrums sessions are mandatory. There are processes where you want to be more flexible about (more below), but there are specific recurring meetings you want to make sure the entire team attends. The team needs a clear structure to follow.
Second, you need to determine how requirements are captured, reviewed and implemented.
There’s an infinite amount of tools out there to increase productivity for software development teams (ok, we lied, the list is not infinite, but it’s fairly comprehensive!). These are some of our favorite tools for different software related functions:
Documenting product requirements/ Backlog management: JIRA
Jira has gained an incredible adoption over the last few years. It’s used by many Agile shops to manage project timelines, workload, sprint backlog, work that’s selected for development, defect logging and so much more.
Visualizing product roadmaps: Aha!
Aha is a great tool to create a product roadmap and to manage ideas and user stories. The tool also allows you to score the stories in a way so you can visually order them by business impact.
Wireframing and Prototyping: iRise
(Pitch Alert! :-) iRise offers a unique, holistic approach to software definition - combining fast prototyping with integrated requirements management to define and design software. Using wireframes and prototypes to drive the requirements process, iRise allows stakeholders to easily review, interact with and validate business requirements, and then manage them through the process. You can also integrate iRise with JIRA, SLACK and all the other major ALM tools, so every team in your SDLC is connected and collaborating.
User Testing and Product Research: User Testing
UserTesting is a platform for getting rapid customer feedback on almost any customer experience you can imagine, including websites, mobile apps, prototypes, and real world experiences. Using this tool to get feedback from customers early and often helps making sure that requirements do not change after a project is handed off to developers.
Team communication: Slack
Slack (acronym of Searchable Log of All Conversation and Knowledge) is a messaging application for teams that is really, really easy to use. It supports real time messaging, file sharing, archiving and search.
Third, you and your team must decide on a clearly documented process on how you log code changes a feature is complete? In other words, if a developer leaves your team and someone takes his or her place, can they access the right tools and documentation archives and learn what was implemented without having to go and check the code?
At the end of the day, the key to a keeping a project on time and on budget is close collaboration. The tools used in everyday interactions are critical to achieving effective collaboration and communication among team members and to reduce the overall cost of software development.
When companies do not clearly document and enforce testing strategies, software bugs make their way to production.
QA testing is one of the most important activities in software development but it’s “one of the most unrewarded and overlooked side of software development.”
In today’s world, users expect elegantly designed software. When bugs are released into production, it impacts the overall return of investment of any software project. Users aren’t very forgiving - there is always another solution for them to try.
Bugs erode brand perception; they cost companies money, time and customers. They result in bad app or website reviews.
In order for a business team to keep their project on time and on budget, the project manager must document and enforce a series of testing practices that are followed by the entire team. Below are some strategies that apply to both online and mobile software projects.
- Test scripts are defined when requirements are created
- All developers are required to do unit testing
- Functional testing is conducted for every flow that is changed
- UX/Comps testing is done by both the creative and the development team
- Performance testing is required when new functionality is introduced
- Load Testing is conducted against the expected peak traffic of of a site/mobile app
- Regression testing is required for the entire flow
- Before moving to production, the team does a formal User Acceptance Testing with all stakeholders.
- For flows including payment processing and Personal Identifiable information, the team is required to do security testing
For mobile applications, project and product managers must also conduct:
- Device testing
- OS version testing and support
- Carrier testing
- Network connectivity testing
- Interrupt conditions testing
- Offline mode testing
- Installation Testing
- Low level testing (memory usage, auto-deletion of temporary files etc)
Be diligent, and enforce your QA process. I know from experience that it’s one of the easiest areas to slack on (no pun intended). You’ve finished the bright and shinny new functionality and want to get it out to the world. Resist the temptation to cut corners and make sure it’s ready for the big debut.
Software development teams have every intention of staying on time and on budget. But in not addressed, the factors we’ve detailed above (and others) can make it a near impossible goal:
- Requirements are not clear at the beginning of the project
- Not being able to control scope changes & scope creep
- Not sorting out cross-functional dependencies and getting alignment around project plan with stakeholders
- Having too many developers on a project
- Not getting alignment on “Must Have/Should Haves/Nice to Have”
- Not using the right tools to maximize productivity
- Not setting the right expectations with developers on coding practices
- Not having a clearly documented QA discipline
I hope that you can use the suggestions made regarding these issues to increase team productivity and create near bug free, exceptional software!
Do you want to learn more about how to run a successful software project? Read our article on “How Do You Become a Great Product Manager? Learn the Secrets of 10+ Experts.”