The Simple Art of Starting a Software Project
Ok, well maybe it is not so simple. I guess that is why there are so many conversations about it (like this one), but it does not have to be so complicated either.
Context Note: for some perspective this applies to a project for the development of a software product, but can really be applied to any software or IT project.
I recently had a conversation about what is the best approach to kick off a project. Should we always start from the ground, working with the end users to understand all their needs, or should we start from the architectural side, working first to understand the technical constraints and capabilities, designing reference architecture before we engage end users. Also, what is the best approach to getting buy-in and what process framework should we use?
The short answer is, it all depends.
First, the process of designing a technical system is not simple; however, all too often, we over complicate the matter by trying to force people (business users or technology staff) down a path because that is the framework or methodology of choice by some “authority”. Solid plans are not created by the rigid application of certain processes (frameworks, methodologies, patterns, etc.), they are developed by using the best aspects of these processes coupled with the knowledge and experience of the people developing them.
Just like choosing a framework or language for developing software, there are many factors that go into the choice, especially if you are in the world of professional services. For example, a client may want you to develop a new mobile solution for them. They want it on iOS but they may consider scaling out to Android in the next year or two. The natural thought would be to go for a technology such as Flutter or React Native; however, this may not be ideal for the client because the client’s internal staff, who will be operating it in the end, only knows Swift. Now, if you expand that business request to be the build of an entire logistics application, including infrastructure, you may find that based on the client’s needs and environmental constraints, you may be piecing together certain technologies that may not be the most ideal. This does not mean that you throw quality to the wind; it means that you need to be creative, you need to find the best use of each technology available, applying them and building a holistic solution that is secure, stable, and valuable. The same is true for the analysis, design, and management aspects of a project.
Secondly, yes, you need the buy-in, to be successful or to at least minimize the pain, but how much depends on the situation. Yes, you should consider end user needs and you also need to consider the architecture; however, you certainly do not want to blow through your (or your client’s) budget and waste people’s time doing unnecessary activities. Sometimes it makes sense to place milestones at various steps, to make sure everyone is on the same page, even before development begins. When it comes to engaging with people, where you begin is not as important as where you concentrate; focusing too heavily in one area could expose you to certain risks.
When deciding on where to start, I simply recommend starting with the person you are currently talking to. Get to know their role in the company and their realm of influence. Ask them what success looks like to them and what it would look like to their end users. Find out about end-user sentiment about their own processes as well as their sentiment towards the technology department. This will help guide you in planning your approach. In some cases, you may need to apply additional effort into gaining the trust of the business or end users (which is also useful for when you are ready to beta test and pilot), but in others, you may be better with a lighter touch. When working with the end users, regardless of the depth that you need to investigate, always show empathy, and always listen. You also need to know the constraints on the technology side, not only with the existing systems, but with the operational aspects (existing staff capabilities, budget, contracts, etc.), and you also need to know about expectations and how people operate. While all these points should be considered, I do not have a formula on how much to apply or how deep to go. Most of these decisions are judgement calls based on experience, critical thinking, and emotional awareness. This is one reason why in-person meetings are good, because you can, and should, be “reading the room” (listening to tone, facial expressions, and posture) when meeting with stakeholders and end users (especially for the first time).
Regarding the right process to use, this too is situational. Do you or your client have unlimited budget (relative to the scope)? Are the requirements clearly defined and fixed? Has any exploration of the requirements or business process been done and to what level? What terminology does your “client” use; does it match yours? The term MVP although pretty standard in the software development world, can mean something completely different to business entities in other industries. Do the parties you are working with even use the same terminology with each other? So many projects have gotten into trouble because people simply did not have the same understanding, and many projects failed to gain support because an organization tried forcing their methods and terms onto another. Regardless of the software you are building, it is much more important for everyone to follow the same process and speak the same language (terminology), than to be using the “gold standard” of SDLC processes.
Now, I am not saying to make things up as you go. There must be a reason for your strategy, and it must make sense. Two common approaches to software development are predictive (i.e., Waterfall) and iterative (e.g., Scrum). If you choose to follow an iterative approach, it does not mean you cannot leverage aspects predictive SDLC, such as going through analysis and design phases (with gateways) prior to the start of development. Does this mean that you cannot do any development in the design phase? No, maybe knocking out some reusable UI components and building a component library makes sense. Does this mean that analysis stops in the design phase? No, you still may need to do more analysis and create more documentation. In fact, you may still do more design and analysis throughout your sprints. Also, use the terms that make sense and resonate with the people you are working with. If you are following Agile but word Agile has a stigma to it, then call it something else.
This diagram IS AN example of a potential cadence; it IS NOT THE model to follow.
What about Lean, can we leverage some of the tools found withing Lean and Six Sigma? Absolutely! For example, during the analysis phase you may want to use tools such as C-TIMWOODS and DMAIC to document and understand processes before designing technical solutions. You may even find yourself creating a value stream map (*gasp*). What about Six Sigma? Where can that be used? If you are developing a solution that generates mission critical data, based on scenarios or conditions, you may want to establish control charts or some lightweight version of Gage RNR to be sure that what you are seeing is in control, accurate, and precise. All these tools and processes should be available to a project manager (or business analyst) to be able to pull from. Just like a tool bag that you may carry with you around your home, you can look into the bag and figure out what tool or set of tools are right for the job. The more tools you have, the more equipped you will be to build something better and faster.
The same can be applied to architecture too. Do you follow the 3-schema approach or 4+1? Do you start with an FDD or DFD or general process map? Should you build out use case diagrams or is creating an enumerated list sufficient? What about personas and how detailed should they be? Should you create a system proposal, or go right into a system design, or something else, and what format should these documents be created in (e.g., Word, PowerPoint)? Again, it depends. That is the art of all of this: knowing what, how, and when to use these tools, as well as how to effectively get buy-in from your stakeholders and end users.
The point is, use what make sense and speak to each other! That is why the Agile Manifesto and the four core values have stood the test of time.
Agile Manifesto Core Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Again, collaboration and communication are key. It does not matter if you are following predictive SDLC, Scrum, Kanban, Waterfall, Unified Agile, or some blended version, as long as you are talking to each other and you are all following the same strategy (this is where project charters are very useful), you can be highly effective. For teams starting out, this may be hard to manage, so it may be better sticking to something purer, but with a seasoned project lead (e.g., project manager, agile master, scrum master or even technical lead) your team can be highly effective in delivering quality and valuable solutions that meet the needs of your clients.