Project Management: 5 Ways to Overcome Its Greatest Challenges
Working as part of several software development projects at UruIT over the last few years, I have faced the industry’s typical project management challenges.
Thanks to Agile development principles, I have been able to avoid many of the hazards that used to haunt me in just about every project in which I was part of the delivery team.
Long gone is the stabilization phase at the end of the project when fixing hundreds of bugs was the everyday chore. Also gone are the conversations regarding the inability of the team to work the exact number of hours a requirement would take. No longer do I have to use a deviation metric to measure how far from the initial budget the project will be. I also can’t remember the last time I had to give up my weekends to get back on track on some really outdated plan.
I have gained much better results, and in this post, I will describe and share some of the hacks I have learned through my experience that have helped me to overcome these and other software development difficulties.
Understand the Project’s Constraints
It is important to devote the necessary time to understand the problem your product intends to solve and the limitations implied in the project that was created to build it. The Agile Inception Deck includes some basic activities that help discover some of the limitations we should be working with.
We need to get as close as possible to the reality of our stakeholders in order to make better decisions as the projects progress. Things like fixed dates, technical or commercial risks, dependencies on other people outside the team, budget limitations, and so on need to be on our radar in order to plan accordingly and avoid nasty surprises.
- Plan some time to get to know and build trust with your project’s stakeholders.
- Discover what’s really important for the success of the product to make better decisions as the project progresses.
- Start working based only on a requirements document.
- Assume everything you need to know is in the requirements document.
Manage Your Budget
It’s challenging to accurately estimate the size of a software project. However, accepting this challenge forces you to develop better skills in scope management, planning, task breakdown, negotiation, and quality assurance (QA). Initial estimation is useful for budgeting, but after that has been taken care of, I find more value in transforming the product to fit the overall budget instead of measuring against individual task estimates and trying to make those tasks fit into the estimated time frame.
Even if it’s not possible to estimate with 100 percent accuracy, the initial assessment is a useful tool to determine the budget and to discover other limits of the project. With the initial estimation, we try to establish the size of the project to know if we will have sufficient resources (time and money) to generate the desired impact.
The ways in which we can achieve that impact, the effort we need to put in to develop the software, and the feedback from the stakeholders will all change in unpredictable ways, but the initial budget most likely will not.
During the execution phase, always try to solve what initially could be seen as an estimation problem by managing the scope—that is, doing less. Finding creative ways to simplify the solution either by choosing less complex approaches or by cutting low-value features from the scope is a much more effective way to get back on track than giving up your weekends.
- Estimate in order to determine your budget.
- Try to deliver within the limits of your project.
- Use scope management as your first project adjustment tool.
- Commit to finding creative ways of staying within budget and time.
- Track estimated time versus actual time at a Task/User Story level.
- Use crunch time to get “back on track.”
- Commit to your initial estimates on a Task/User (even Sprint) level.
Prioritize and Break Down Work
I am convinced that 80 percent of the value of a product is delivered by 20 percent of its functions. With that idea in mind, once you have at least a basic understanding of the project’s limits, it’s necessary to prioritize based on the estimated cost-benefit ratio.
One of the most effective things I discovered in software development was when we changed from layered development to vertical development in short iterations. This means splitting the work into small increments so that within one week, they can be developed, tested, and installed in at least one QA environment that’s accessible to users.
When you break down your product, keep in mind that you should do it in order to deprioritize part of that work. Bigger chunks of work might lead you to build a lot of unnecessary stuff just because it was written in an atomic way. Use this guide to find helpful strategies when thinking about breaking down your backlog.
- Split work into small vertical slices (use INVEST criteria).
- Deprioritize slices with the least cost-benefit ratio.
- Deliver working software to users as soon as possible.
- Divide work in layers (for example, database, back-end, front-end stories).
- Work in stories bigger than a week.
Quality shouldn’t be negotiable. Unless we are building a disposable prototype, each increment delivered must have the highest possible level of quality both internally and externally. And every detected error must be resolved immediately, if possible.
The lack of internal quality generates technical debt and maintenance problems; the lack of external quality generates defects. Both end up being very expensive in terms of time and your relationship with your stakeholders, especially toward the end of the project.
- Work in small increments to test and deliver features sooner.
- Include code reviews in your process to boost internal quality.
- Use automated tests at different levels (take a look at the test pyramid).
- Complete all the testing in a “testing phase” at the end of the project.
- Hand over untested code to an external QA team.
- Try to go faster by not testing properly; go for decreasing scope instead.
Deliver as Often as You Can
When we work in an iterative and incremental way, in a few weeks we should be able to install a first version of the product in an environment accessible by the client and, if desired, by their users.
The level of anxiety experienced by the sponsor and stakeholders will decrease with each consecutive delivery as they can see a quality product growing after each iteration and even more if it’s possible to use it before the end of the project.
This will make things much easier if we need to suggest a decrease and change in scope in order to meet the project limits, such as budget or dates. And you will probably need to do that, since it is expected and even healthy to get tons of feedback from the users who are working with the early versions of the product, often making the initial project plan totally outdated.
- Show your progress by delivering working software.
- Expect a lot of feedback from the moment you start releasing.
- Show the effect of feedback on the plan and readjust everything as needed.
- Use prioritization to incorporate feedback by removing low-value requirements.
- Show your progress by delivering only an updated plan and some screen mock-ups.
- Release only at the end of the project when there are no resources left to adjust the product.
Use These Principles to Find Your Own Way to Overcome Challenges
Effective project management is a learning process. Putting into practice some of this advice can definitely give you some insight into how we manage to deliver valuable solutions within the most common constraints of software projects.
Thanks to effective prioritization, the most valuable elements of the initial specifications will be developed and delivered on time.
To effectively prioritize, you will need to fully understand your project constraints and manage the feedback loops so that you can honor them.
And, most importantly, by consistently delivering quality software, you’ll build a strong relationship of trust with your stakeholders!