Let’s face it Fintech is hot these days. Almost every day, a new killer app or internet product is released that can help us save, invest smarter, pay bills, transfer money, and more. With the urgency to bring these new products to market, delivery teams are frequently tempted to go “lite on process." In this blog, we will discuss some of the most common pitfalls in Fintech software project delivery and how to avoid them.
There is much more to know about project management than one can learn from books, training, and certifications. Some knowledge is acquired through real-world experience.
1. Under-skilled/Undermotivated Team
There can be as much as a 10-to-1 productivity ratio between a “great” software developer and an “average” software developer. If your team members are sub-par, you are starting off with a losing hand. No matter how effective you are at managing a project, unskilled or unproductive team members can kill your project. For instance, they may deliver products late, implement code with a high defect density, and or ignore requirement specifications. You can't always have a "rock star" team, but the end result may not live up to your organization's expectations if you start out with bad ingredients.
2. Unrealistic Schedule Expectations
Like all other aspects of your organization, delivery teams are expected to evolve and change at a dizzying pace. Let’s face it, more often than not, your project stakeholders need your project to be implemented yesterday. It’s good to be agile, nimble, and responsive, but creating and committing to unrealistic schedules does not do anyone any favors. Be aggressive with your plan, but be realistic.
3. Not Realizing or Accounting for Non-development Tasks
Does your delivery plan include ALL of the tasks necessary to deliver the project? Are you sure? Don’t make the mistake of including only “development” related tasks in your plan. The plan should include project-related efforts that go beyond the obvious “Design, Code, Test." Don’t forget to include necessary tasks like detailed requirements elaboration, requirement feedback cycles, business requirement churn and technical training for team members. These crucial tasks should not be excluded from your baseline project schedule.
4. Shortchanging Requirements Definition
Many new project managers feel that anything that doesn't involve writing code is overhead and is, therefore, a waste of time. We all know that you want to be responsive and agile with your project stakeholders, and that’s good. Responsiveness is good, However, developing code and then re-developing code is harmful to your timeline, workflow, and budget. Before coding, make sure that you have the required details and that they are defined to a level where they can be tested. We are not talking an old-school waterfall approach here. You do not need to know every feature and functionality of the entire system before coding can begin. Break your project into logical iterations, gather detailed requirements for iteration #1, then have the team start coding iteration #1 while the requirements team moves on to requirements for iteration #2. Continue this process for all iterations.
5. Underestimating Testing Effort
Most project managers struggle with estimating and planning the effort required for testing. This is the most common reason that projects seem to be on schedule until testing is in full swing. A good rule of thumb is that testing and defect repair should represent about a third of your project delivery effort. In the days of waterfall, testing began when development was complete. A better approach is to start testing as features are complete. If your project budget can’t support this testing effort, at least begin testing at the completion of each functional iteration. If your project doesn't consider this reality, you will either deliver late or deliver a product of poor quality.
6. Scope/Feature Creep
“Requirement adjustments, " “feature requests,” and “just one more thing” type changes are not the exception. They are the rule. As the project progresses, project stakeholders learn more about their needs. They come up with new features and ways of improving existing ones. Don't let these changes drive your plan and your team into the ground. In most cases, you can’t just say “No," but you can control how your process and account for these requests. Gather, analyze, and document the requests. Communicate the impact the changes will have on the plan and collaborate with your project stakeholders to work the features into future releases. The perfect product is rarely delivered on the first release. Deliver on your existing commitments, and try to schedule as many of the change requests into a subsequent release.
7. Throw the Delivery Plan Out the Window
Even the best-laid plans can run into trouble, but do not abandon process and rigor in managing your project. No matter how great a performer you are, team members will underperform, customers will have change requests, and unforeseen technical issues will arise. How you react to these challenges can make all the difference. When your project deviates from the plan, adjust and evolve the strategy. Don't abandon it or take "shortcuts." Without a realistic updated plan, you cannot have open and honest communication with your team or your project stakeholders.
