Whether you are developing your own product or taking on a new client project, the first issue that needs to be tackled is identifying how the end result will be created. For client work, this is more important because you will always be judged on how the client perceives you to be meeting their requirements and not on your actual performance. The right project management allows you to avoid this conflict of interest by prioritizing progression by focusing on:
- Priorities that are important to the success of the project.
- Aspects most noticeable to the client.
- Features that allow others to start making their contributions.
- Simplifying complexity of individual components.
- Versions to be produced for specific purposes.
With the right order of progression, you will be able to ensure that the client perceives to see progress whilst there is actual progress in the development of the project. It's a delicate balance to identify the right project plan, as listening too much to how the client wants the project to proceed can lead to problems in efficiency and other aspects of the project that affect both the delivery date and quality of the end result.
Certainly in the short term, doing everything possible to make the client see progress will have many advantages for keeping their confidence in your ability; it is often tempting to take shortcuts to achieve this. In the longer term, this approach usually leads to many problems—especially when the project has a higher level of complexity. Examples of these problems include:
- Research that hasn't been thoroughly verified - Regardless of whether you are a journalist, business consultant or a software developer designing a data flow model to match the client's specifications, research that hasn't been verified for its accuracy will lead to the end outcome of the project being flawed.
- Work that hasn't been structured to provide flexibility - It doesn't matter whether you're a programmer writing software, a designer setting the layout for a brochure or someone creating a report document, it's almost always a guarantee that there will be a need to make some type of change(s) to the original requirements. If the work you've created isn't structured with efficiency and maintainability in mind, these change requests are likely to cause havoc that introduce scope for mistakes to be made and an increased amount of time required to make them.
Make a note
Imagine creating a website or software application that contains 100 pages/screens; each having their own headings, font styling and other visual presentation features. Everything has run smoothly on the project until the end, when the client asks for a last minute change to the fonts and color schemes used; this would be a 2 minute job if the work was done in a structured manner, but a serious task that could take a week or more to develop and test if the work had been developed in a rushed way without thought to structure and maintainability.
In the worst case scenario, the unstructured approach to developing this project would result in the requirement for manual alteration and testing of each individual screen, while the structured approach would only require minor modifications to a presentation settings file—such as a CSS stylesheet used in websites and web based applications.
- Verification that hasn't been thorough - No matter what type of software development you are involved with, it's important to constantly check the work produced so far to make sure that all components fit together. Skipping on this leads to more corrections that need to be made at the end of the project, meaning that the client can't rely on the work until it is fully complete; an issue that can be improved with a structured testing and development methodology . At least by investing time to perform verifications during the development of the work, the client can access previews that are more reliable for them to demonstrate or use to add their own data, information and suggestions
In most cases, the client will be eager to see progress on the development of their project. The relationship between the two types of progression philosophies and the client's confidence in your ability to deliver is demonstrated in the following diagram:
As can be seen from the above diagram:
- The structured way of working starts with a much slower progression than the unstructured ad-hoc approach.
- The progression rate of the unstructured approach decreases over time, whereas the structured approach starts to gather momentum.
- At some point, the pace of progression for the structured approach overtakes that of the ad-hoc approach.
- At some point, the ad-hoc approach leads to being unproductive—resulting from having to replace previous work due to change requests that take much more time due to the inflexibility of the work produced.
- The grey area between the progression of the two approaches represents the amount of panic by the client. The ad-hoc approach allows the client to be happy at the start of the project, but results in panic at the end, whereas the structured approach starts with a panic and ends with the client being happy and confident.
With the exception of prototype and throwaway projects, the structured method is clearly the way to go, as it allows for the best outcome in terms of time to deliver, quality and efficiency for future maintenance and expansions; the use of formal methodologies can be used to deliver a structured roadmap and identification of when tangible results are to be expected. The main problem with this approach is that it starts with a panic from the client and could be disastrous if not managed properly, possibly leading the client losing faith and abandoning the working relationship before the project reaches the point where they see the benefits. This is especially true for client personalities that show big elements of impatience (see Chapter 6, An Introduction to Client Types). There are two options to resolve this:
The first option for building the client's confidence is to carefully identify how to trade off the most structured methods of progression against the quick and unstructured. As can be seen in the above diagram, this isn't ideal, but it at least allows for a good level of efficiency and isn't a bad thing if the budget and deadline for the project allow for it. The key to succeeding with this strategy is in selecting the least critical elements of the structured approach to trade for the most noticeable and least flawed elements of the quick and unstructured approach, hence allowing you to satisfy the client without compromising your longer term progression and efficiency capabilities.
The second option, illustrated in the above diagram, starts with a set of resources that allow you to start several steps ahead in the project. These resources could be developed by yourself, accessed as open source tools or purchased depending on which options best suit your strategy. Examples of these resources include:
- Document templates for common types of report—e.g. business plans and sales reports.
- A code framework for software, making it possible to produce complex features more quickly.
- Template designs for websites.
- Ready made open source software—such as Wordpress for managing blog websites.
- UI framework for designing user interfaces—e.g. Bootstrap for websites and web apps.
- UI wireframe prototyping—i.e. creating visual mockups before the production of UI code.
- Royalty free stock photography for use in websites and brochures.
- A model library for animators, allowing scenes to be built quickly with common objects like tables and chairs being ready to drag and drop into scenes.
Whichever resources you select to enhance productivity, it is important to choose the right ones that are in general good quality, can be used with each other and that fit into your way of working. When researching the types of resources you will be buying or developing, you should pay special attention to finding answers to:
- How flexible is the resource for the range of projects you expect to deal with?
- What level of flexibility will the resource offer when clients change their requirements midway through projects? Does the resource make it easy to undo work such as by altering various settings?
- Does the resource impose any restrictions? If so, how could this affect your projects in worst case scenarios?
- What is the difficulty level to learn to use the resource? Will this introduce a problem if you need to bring other people onto the project?
When working with scenarios and/or clients who are difficult to predict, the best way to tackle the project will often be to identify in clear terms what can be provided for an initial version and then build on it from there; this being the minimum viable product (MVP), with new features being added with incremental releases. This will provide you with two main advantages:
- Faster route to market so that you can start trading sooner.
- Recover your investment sooner.
- Enable the system to begin funding its own future development.
- Allows you to test the market and develop future features in-line with identifications of market trends.
- Avoids the risk of investing in features that unexpectedly fail to generate an interest and therefore fail to recover your development investment.
- Allows you to make informed decisions about your product development inline with what your audience wants - and not what you think they want.