:quality(90))
What comes to mind when you think about running a web app project?
Maybe you’re familiar with the well-beaten path they follow–laid down by hordes of past software development projects. It begins with scope definition, making way to estimates, and finally reaching the summit in the design-delivery-testing cycles.
While these may be familiar landmarks, there are many different paths to reach them and even some shortcuts. Keep in mind even the best-planned expeditions take unexpected turns. A survey by Geneca shows that 75% of teams lack confidence that their project will make it to the end of development. Without a trusty navigator to make course corrections and track the budget along the way they would never be triumphant.
We’ve completed this journey many times and, to be honest, even learned a few things the hard way. But hey, it’s all part of the process when charting new territory.
This post will cover what we’ve come to find, based on our experience, as the best way to approach running a web app project. Hopefully after reading this you’ll be better equipped to navigate your next software development adventure. Without further ado, your project management tips!
Before the project starts
01) Defining the scope
Often, thinking of the scope, we envision a list of precise features, described in as much detail possible. This level of specification is time-consuming, and unnecessary. What is necessary, however, is to know which values the product will bring customers. If you haven’t already, check out our tips on preparing product specs—it has a handy template for creating the perfect spec sheet.
02) Creating an estimate
Developing a product is a creative process that’s intertwined with the discovery phase. It’s unrealistic to estimate the entire scope, feature by feature, in the very beginning, and adhere to it as the project progresses and evolves.
At the same time, financial predictability and planning are among the most important aspects of a product’s success. So what should we do?
Instead of estimating features, try looking at business values. For example, we need to notify our user about some action on the platform. This can be accomplished in many ways: send a push notification, email, SMS, or even call the user.
In most cases it doesn’t matter which option we choose. The point is, we need to get this user notified, which gives us very tangible business value.
In this case, the type of notification can be determined further down the road based on the initial feedback collected or knowledge gathered from the progress already made with the product. This allows us to start fast and to verify assumptions on the go.
However, if required we have some useful tips and strategies about creating a full-fledged estimate.
03) Choosing a technology
Technology choice is a very complex topic and deserves its own discussion. This decision belongs to the entire team. Just make sure you consider every aspect, including your team’s experience with it. Check out the linked post for more information.
Implementing processes and keeping up with them
Contract signed. Milestones determined. Technology selected. When you find yourself here, what comes next?
04) Organizing meetings
We can start with the simplest task: setting up the recurring meetings recommended by the scrum methodology.
The most essential, but often underestimated meeting is the daily standup. It is important to make sure all team members are informed about the schedule and are OK with it. There’s nothing you want less, than a team member habitually missing the standup because the set time is just not right.
As for the planning and sprint start, consider setting it up during the week, not on Monday. Mondays are usually filled with other meetings and are in general too stressful—not to mention their bad reputation.
Another important meeting is the sprint review. Don’t wait, set it up after the very first sprint. You’ll be sure the client’s always aware of new project updates. And remember: there’s no such thing as “there’s nothing new to show at this time.”
05) Establish scrum guidelines
The next thing you might consider is working on the Definition of Done (DoD) and Definition of Ready (DoR) both for sprints and individual tasks.
It is important to define what’s expected at the beginning and end of each sprint to eliminate blockers and misunderstanding.
DoDs and DoRs are dynamic, so concepts will have to be refined as the project progresses and adjusted to every product development stage.
06) Continuous delivery
Another important process of project development is continuous delivery. This approach reduces the stress and uncertainty related to a big release at the end of a project.
You will simply have the project completed in smaller parts and be ready for potential users at any point during development.
Another benefit is your client stays involved and they have the opportunity to “play around” with the software from day one. Nothing short of actual interaction with the product allows the client to understand whether it is headed in the right direction while mitigating the risk of misunderstanding the product goals.
07) Keep an eye on the budget
Make sure you monitor if you're on track with delivering features and that the budget is still sufficient. Incorporate this into your sprint routine.
The results of your analysis should influence every subsequent sprint planning. Check what needs to be done to deliver the upcoming business value and don’t be afraid to cut the scope and get rid of some nice-to-haves if necessary.
Quality backlog management is a crucial aspect of successful projects. As project managers in Monterail, we take ownership of this segment. In most cases it’s needed to make sure all the tasks in the sprint are ready to grab and implement without any additional questions.
08) Follow established Definition of Ready
Try to follow DoRs as strictly as possible. On one hand you prepare valuable content for the team and spend less time answering questions. On the other hand you can see if the definitions you prepared in the beginning suit this particular project.
Spoiler alert - they won’t. That’s why it’s important to review and refine your definition of ready to achieve something accurate and have a helpful template you can use to describe every task in your backlog.
09) Consider how you split tasks
Suggesting to split tasks to the smallest level possible sounds obvious. But once we start thinking of the business values and not features, it’s not so straightforward.
Make sure every task contributes to the value of the product and isn’t just an accumulation of code lines. This is also reflected in how you deliver individual product features.
For example, when implementing a complex form with multiple fields (example name, address, an option to upload a picture, etc.) tasks are distributed between the front and back end.
You could split the presentation and data access layer tasks and merge them in the end when everything is complete. The problem with this approach is that the form has zero functionality until every line of code is complete. But there’s another way…
Instead, we can approach this horizontally. Take individual elements of the form, say name entry, and complete the front/back end work field by field. This way functionality and value are delivered quickly.
10) Be tactful in the backlog
The backlog is never finished. It requires constant minor improvements and adjustments. So it makes no sense to go too far ahead of yourself.
Make sure the backlog for the upcoming milestones is well defined and don’t waste time refining something that is planned far in the future.
It’s good to keep a high-level overview of features, but the details should be defined when we reach that point in development.
11) Keep the backlog communal
Try not to prevent—instead, encourage—other team members adding tasks to the backlog.
It may be a technical enhancement or a nice to have feature for the future. Regardless, it’s worth keeping everything in one place not to let anything slip through your fingers.
12) Create easy to share project documentation
Think of the tasks in the backlog as your project’s documentation—this will save you tons of time preparing it. To create backlog content, you can use tools such as Ivory Research.
Ensure it’s up to date and you’ll always be able to share it by simply exporting it from the tool you use. ...exactly what tool are we talking about?
13) Select an Agile issue tracking tool
Choosing the right project management tool will set the tone for the entire project development process and determine how much effort you need to put into delivering backlog items and catching potential irregularities or bottlenecks.
My all-time favorite, as an agile project manager, is JIRA, I love absolutely everything about it—from user interface to almost unlimited integration options and multiple report options. Although, there are many great alternatives out there -don’t be afraid to try them out and God bless the free trials 😄
Communication
Communication is a crucial part of any successful project. How do you balance keeping everyone in the loop and being overwhelmed by information?
14) Find out who’s who and plan communication
Before anything, make sure you know who to contact in which situations. If there are multiple contacts on the client’s side: know who’s responsible for what.
Communication should be planned. Make sure you have established touchpoints where you update your client with the current progress during the sprint.
There’s no need to reinvent the wheel here. Scrum offers us a sprint review meeting, which suits this purpose perfectly.
An additional value this meeting brings is awareness. It’s a great reminder that we need to have a business value delivered every sprint, so start thinking about it already in the planning phase.
15) Practice transparency
Be honest with your client and don’t embellish the actual state of affairs. When something goes wrong, even if it’s our fault, the client has every right to know about it and influence the way we make it work again.
Being open about the status of the project will allow us to build mutual trust.
16) Pass the mic
Don’t try to be a proxy for the entire communication flow within the project. Encourage your team and the client to communicate with each other.
Not only will it make the response time faster, the client and the team also learn how to work together and establish expectations from each other.
However, once the communication becomes an obstacle for product development, make sure to step in and take over and clear up some space for the actual work.
17) Don’t be a hero...
Listen to your team. Even the most experienced project managers struggle to predict every possible situation in the project. So by all means, don’t hesitate to ask for help.
There’s nothing shameful in admitting that you do not know something. You’ll find it’s beneficial to the project and relationship with the team.
18) ...but be brave
Do not be afraid to act, even if it leads to a mistake. There’s nothing worse you could do than remain passive and just let your project move forward by itself.
Make sure you’re aware of what is going on and what’s coming next. Think a few steps ahead and try to predict what could go wrong or right and prepare for it.
A note before you leave us
Hopefully these tips help you run a successful web project. It’s no rocket science, mostly common sense. You’re never alone in this process; your team and your client care as much as you do about the project’s success. In conclusion, simplifying all of the above: listen to each other, be honest, and do the best you can every day. In software project management, approaching all our projects this way has worked well for us and will for you too.
:quality(90))