How do you start up a project idea?  How much time and effort do you put into product planning, prototyping, product development and product support?

Advertisement:

Below is a rough guide to how you should start up a project (exec summary: start with defining the problem(s) and solution(s)).

I have blogged about app workflow here (mostly for public apps).

Choose a Methodology

Early on you should choose a project management methodology, Agile is a popular (no lock-in) methodology compared to the older/less-flexible Waterfall or PRINCE2 methodologies.

I am a fan of the Agile methodology as it allows for inevitable frequent and required pivots over the more rigid locked down methodologies of the past.

Agile Software Development Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Methodology and Practices (Stages)

1. Inception Phase

• Form Initial Team (Stakeholders)
• Develop Common Project Vision (What is the problem)
• Align with Enterprise Direction (Integrate where possible)
• Explore Initial Scope (MoSCoW Method)
• Identify Initial Technical Strategy (testing, draft, final, support)
• Develop Initial Release Plan (Goals)
• Form Work Environment (remote, onsite etc)
• Secure Funding (after whiteboarding)
• Identify Risks (what if…)

2. Construction Phase

• Produce Potentially Consumable Solution (Minimum Viable Product/Minimum Value)
• Address Changing Stakeholder Needs (Pivot)
• Move Closer to Deployable Release (Iterate)
• Improve Quality (Measure)
• Prove Architecture Early (Test)

3. Transition Phase

• Ensure Solution Is Consumable (Signoff)
• Deploy Solution (Test and Deploy)

4. Ongoing Goals

• Fulfill Project Mission (Complete Must-have backlog)
• Grow Team Members
• Address Risk
• Improve Team Process and Environment
• Leverage/Enhance Existing Infrastructure

First, you will need to define the problem(s)

First, decide on what the problem(s) are and are aiming to solve?  After the problem(s) are known you can discuss and validate possible solutions before any coding is done (billed). The business requirement will drive the technical requirements/directions,.

Letting technology goals drive the project is a bad idea.  Why do you need XYZ? Is an app required after all? Does an “off the shelf solution” exist already?  Can existing processes or software be tweaked?

You will need stakeholders (or stakeholder proxies)

Choose customer stakeholders (or customer proxies) that are engaged and positive, build a team of about 5 people who can drive the decisions and who understand the problems. Involve key stakeholders early and capture problems in a formal setting

• Identify the stakeholders and establish a team
• Document the problems (as it is and not how it should be)
• Identify and specify improvement points
• Plan solutions and Iterate

Improving a process or product should be measurable and agreed. The main aim of a customer/stakeholder is to create validated user stories that define the problem(s) and solution(s) from the end users perspective.

Example user story formats (snip)

• As a <role>, I want <capability> so that <receive benefit>
• In order to <receive benefit> as a <role>, I want <goal/desire>
• As a <role>, I want <goal/desire>
• As <persona>, I want <what?> so that <why?>
• etc

Whiteboarding

Whiteboarding is a great way to get everyone on board (and on the same page). One person may assume that something is a certain way but another person from the trenches may say it is not the case at all. It is key that problems reported lower down the managerial structure are listen to and be valued.  Accept any problems and add them to the backlog (prioritizing comes later).

Whiteboarding should build a backlog of ideas and common understanding of what the landscape of issues are. I use a tool called Mind Node from https://mindnode.com/ to map things electronically. Within minutes you can have a map of connected or not connected areas of interest.

Backlog

A backlog is a place where you can document issues and break issues down into tasks.  I have blogged before about Developing software and staying on track. You can use software like Trello, JIRA or Excel or notepad.

Backlogs should have crazy ideas and things that will never be developed. Agile development iterations should only pick the best items to work on.

Trello offers basic shared lists management

Jira offers a more complex Agile backlog management suite

Mockup Prototypes

It is important that you develop validate ideas with on device/screen with mockups/prototypes before coding something.

I use Platforma web and Platforma mobile prototyping tools with Adobe XD to prototype before development.

Agile Terminology in Backlogs

Whiteboarding and Backlogs can allow you to capture Epics, Stories and Tasks. Once tasks are prioritized they can be picked up and complete in Agile work sprints.

• Epics are the bigger user deliverable objectives like a “usable web-based solution”, “usable iOS mobile app”, “user Android Mobile app” or other long-term objectives.
• Stories are smaller things like “deliver back-end server infrastructure”, “Deploy a working prototype of feature X”, “Build an API (Application Programmer Interface)”. A user story can usually be completed in 2 weeks.
• Tasks are often subtasks to stories and can be done quite quickly.  A task could be “Change the colour scheme”, “Set up a testing environment” or  “Deploy the alpha release”.

Prioritize the Backlog Often

Prioritize items in the backlog often using the MoSCoW Method.

• Must-Have
• Should Have
• Could Have
• Won’t Have

Do not work on won’t have and focus on Must-Haves first.

Define the Solution and Minimum Success Criteria

The following graphic is well known within the Project Management community.

How would you feel as the customer knowing that you have not been understood and that you may not get what you need?

How would you feel as the developer not knowing fully what you need to deliver?

No one likes to double back or waste time and resources unnecessarily.  Define and plan early. “Failing to plan is planning to fail.” Benjamin Franklin

Technology Requirements

The backlog will drive the requirements; e.g:

• mobile app or web app
• type of technology needed
• the location and number of servers
• number of prototypes
• scalability and redundancy

Knowing the requirements drives the technology. Technology drives the work and the budget.

TIP: Be wary of contractors that quote before listening to your full requirements. I was once told by a contractor that their main job was to “Con” “and Insult” you.  If you accept a quote before saying what you need is a guarantee that you are paying a load of profit.

Now What

If you have defined the problem well, have good user stories and validated with stakeholders you are on the right path.

Be prepared to pivot and set frequent milestones to launch value (RERO).

Obviously centralised web-based technology is easily updatable compared to compiled and distributed mobile apps so choosing the right technology early is key to success.

Security and Quality

This is the project triangle where you can choose two sides (not three)

 

Quality is a given so you must choose that, the other given is secure in my opinion.  I have blogged before about securing Ubuntu in the cloud (checklist), running security audits, installing WordPress WordFence Firewalls and WordPress Anti Malware plugins along with updating OpenSSL and applying kernel patches to protect against Spectre and Meltdown securing issues.  Supporting an app is serious stuff and often deployment is the start of the real work.

Maintenance

Will you need to recompile apps to meet iOS or Android requirements?

How often will you release updates? What percentage of devices do you want to reach?

What “service level” will you set for concurrent users, uptime and failover?  What priority will you give to backups and snapshots of the environment in case you need to restore to a previous state?

Past Lesson learned

Obviously, the larger the project and higher levels of storage/reliability/security the more checks and balances need to happen.

The Australian Bureau of Statistics contracted IBM to handle the Australian online census in 2016 and the major failure and report into what the identified problems were was an interesting read.

• The ABS website was pulled down on the night of the study, with it then being unavailable for about 40 hours.
• The ABS is judged to have failed to communicate with the public properly about major
• IBM is deemed to have failed to properly test its disaster recovery processes
• IBM had failed to properly plan for how to bring systems back up again.
• IBM’s failure to have tested a router restart, or have a backup synchronised and in place, appears to have been significant contributing factors to the failure of the eCensus
• In his report, meanwhile, Mr MacGibbon also found that the long-term, almost exclusive, relationship between the ABS and IBM had contributed to the problems by meaning any external questioning or oversight was absent.
• Read more about the report.

As a minimum, you should plan and discuss early on about the performance, reliability and uptime targets for any app.  Personally I have moved between multiple cloud providers (CloudAnt, Digital Ocean, AWS and Vultr) to comfortably meet cost v performance (each app WILL have different requirements)

Type of app

The type of app (Web, Desktop, Mobile) you will need will come after discussing the problem, focus on the problem(s) and not the solution(s).

Conclusion

Do’s

1. Keep Source ownership and IP (never let contractors own the code or processes)
2. Insist on frequent handover often
3. Do plan for updated version with major OS releases
4. Do secure the app
5. Do plan for maintenance of the app.

Don’t

• Lock into expensive maintenance contracts.
• Ensure the vendor is passionate about solving your problem and not the invoice they will submit.
• etc

I hope this guide helps someone.

More Reading

Making your first Android app

Making your first cross-platform mobile app

Making your first cross-platform app with Electron

 

Ask a question or recommend an article

Revision History

v1.1 added More Reading

v1.0 Initial post