Thinking hard about a project launch - The Oasis Digital Blog

Here at Oasis Digital, we are always agile, and depending on the project needs, sometimes use Agile (in the “capital A” sense) processes extensively. Yet regardless of agility, iterations, steering, and so on, the planning and decisions made at the beginning (and in the early months) of a project often have profound and very difficult to change consequences later.

Therefore, while we would never argue for the straw-man Waterfall, we aim to think very hard about a project at the beginning.

Here are some questions to help form an agenda during planning, launching, and replanning.

Context

Of course a list like this has questions that make sense for one project or situation, but not another. The context covers much of our work at Oasis Digital:

This list is discussed most around the beginning of a project – although of course some of it applies both before and after that time.
Much of this applies to projects between a few person-months and hundreds of person-months overall effort.
These questions are for projects where an Oasis Digital team is engaged to create software for a customer (as opposed to projects where we are engaged as outside experts to advise or assist on a project executed primarily by our customer).
These questions typically are discussed by leaders and experts; not every developer on a project must think about all of this.
This list might seem overwhelming, but Oasis Digital leaders talk about these ideas regularly and are able to move through a list like this quickly.

Customer and Interaction

Customer goals

Do we understand our customer’s goals?
Have we listened carefully to all the right stakeholders?
What are the short-term goals?
What are the long-term goals?
Are we optimizing towards those actual goals, avoiding too much distraction of secondary goals?
In cases where a customer isn’t ready to discuss long term goals yet, do they understand the impact of delaying that discussion, on the quality of our advice and decisions?

Customer communication

What is the right cadence for communicating and demonstrating progress on this project?
Will we communicate progress updates in writing, such as via email?
Will we communicate progress updates on phone/video conference meetings?
Will we send recorded video demos, so that our customer contacts can more easily share the progress with other stakeholders in their organization?
Will we use a shared issue tracking and planning system?
For issue tracking, have we consulted the experts at our sister company Expium, who may counsel us to use Jira and Portfolio for Jira on larger projects?

Project Scope

Features

Do we have a good sense of the high-level features for the software?
Do we understand the features for the parts of the system we are working on first in enough depth to begin?
Do we understand who (in the abstract sense) will be using these features?
Do we understand the success criteria for the features?

Quality and completeness

Have we reviewed our software product quality checklist to determine which of the items are in and out of scope for the project?
Specifically: support, operations, appearance, UI/UX, security, accessibility

Appropriate process for project size

Are we doing the right things, with the right depth and complexity around our processes, suitable for the size of this project?
Are we avoiding large project complexity on a small project?
Or skipping proper planning considerations on a large project as if it were a small one?

Overall project size vs budget

Keeping in mind the goals, feature breadth, quality, completeness, and scale, do we have a sense of the overall effort of the project?
Have we estimated by a few different means, such as counting features, counting screens, and comparing to similar past projects?
With all that in mind, are there reasonable expectations around the overall scope versus overall budget (time or money) for the effort?
In other words, is there a reasonable probability of the overall effort being a success, regardless of whether the initial technical effort is successful?
If this fit is tenuous, have we urged our customer to consider other directions?

Technology

Runtime scalability

Do we understand the approximate size of the user base?
Expected number of installations?
Expected total usage per installation?
Quantity of data that will be processed?
Surges in usage versus continuous usage?

Language, platform, tools

Is the platform/language being used for this project suitable for the customer’s goals?
If we have proposed the tooling, does our customer really understand the trade-offs and agree with them?
If the customer chose the tooling, have we met our responsibility as consultants by discussing with them the trade-offs of that choice?
Is the platform at the right level of abstraction?
Or will we need to write a vast amount of low-level code because the tools are too low level?
Are we using too high level of tool, where we may have to work around it to achieve fine-grained control to meet critical customer needs?

Appropriate sophistication

Are our language(s), platform, and tools strong enough technically to build this project?
Are we at risk of starting fast with a simple approach, then finding we must replace all the early work?
Conversely, are we over-engineering a sophisticated solution for a problem quickly solvable with simpler tools?

Off-the-shelf solutions and building blocks

Have we explored or recommended an off-the-shelf solution to avoid writing the custom software?
For example, could the customer’s needs be met with an off-the-shelf issue tracking system like Jira plus some plugins?
Should we use a sophisticated data grid control, and could that replace portions of an otherwise custom user interface?
Should we use an off-the-shelf data analysis UI, and might that replace portions of a custom user interface?
Are there any other products that could be used to significantly reduce the total effort for the project?

Project Team

Team

Do we have the right team for a project of this nature?
Have we gathered the right people to do it?
Is the team sufficiently large or sufficiently small?
Are enough of the team members up to speed on the technologies for a fast start?
For team members who need to learn one of the technologies, is there someone available to guide them?
Are we planning a realistic ramp-up from a core team to a broader team over time?

Team Collaboration

Have we arranged suitable team collaboration technology and schedules?
Have we considered time zones, for teams that are broadly distributed geographically?
Is everyone on the team already comfortable working collaboratively, or are there any new team members not yet familiar with our way of working as a team?

Starting together

As we start, are we working together as a team intensely, to build a shared understanding?
Have we planned sufficient collaboration time for this initial shared understanding?
Do we have any concrete software artifacts yet that reflect our understanding and initial progress?
Have we already stood up CI and a demo environment? If not, why not?

Scaling out

Are we on a path to defining parts of the project so that we can shift from working together to working in parallel?
Do we have a realistic sense of how quickly that will happen, given the project’s features, technology, and other attributes?

Staff development

Is each person on the team at a point in their development where they can contribute?
Does each person on the team have a reasonable path forward to advance their own skills by contributing?
Is there a well-qualified leader at the start of the project?
Is there at least one other team member well-suited to rise into that leadership role as the project grows and continues?

That’s a lot of questions, and we could probably write just as many to add on. Still, with a bit of wisdom and balance, some of these things will be addressed quite tersely, while others get a lot of conversation, depending on the details of any given project.