On many occasions we have been asked about our project management and development process for delivering websites and web projects. There are highly regarded project management systems like Six Sigma, Agile (including methodologies like Scrum, XP, Kanban, Crystal etc.), Rapid Application Development and Lean Development, and while we’ve borrowed from these, at Lift we’ve designed our own project process.
We’ve coined our process “The Lift Way”. With years of experience and hundreds of successful projects under our belts, we were well-versed in a variety of project management tactics. As we tried different ways of doing things, we soon realized that we needed a specific process that suited us perfectly. To uncover a process that was uniquely Lift, we used Design Thinking to craft our own way of applying project management principles to our projects. It’s interesting what we came up with and how we’ve evolved.
If we were to create an ideal process, we knew we needed to think about all the different types, sizes and complexities of the projects we encounter. We had to consider how completed projects should be delivered, how our clients would convey their requirements to us, and how the constraints of time and budget could be turned into opportunities. While we have very high expectations for every Lift project, there are things that are out of our control that may affect its quality. So how could we provide the very best end product possible in these challenging situations? We’re a team of optimistic thinkers, so we fully believe in our clients’ projects. How could we encourage this passionate buy-in while also adhering to the project scope?
In answering these questions, we arrived at our own unique project process. We’ve taken aspects of many of the popular project management systems and rolled them into our own.
From Agile management we’ve taken “iterative development” and “user stories.” A central tenet of Agile development is that since users use software for their own purposes, the user is at the middle of the development process. We agree. Agile development, like the name implies, is about quick bursts of effort and short iterations of development based on user stories. Our user stories (we call them personas) are the centre of our development and serve as a way to determine which features matter. We also prefer to work in short intense bursts of effort to finish key features quickly so we can test their efficacy with real users.
From Lean we’ve incorporated the “test everything” mantra. Sometimes a feature with no utility sneaks into a project. It could be a stakeholder’s pet feature or a legacy feature that no one really wants but everyone thinks they need. We’re not afraid to challenge our clients about these features and we stick to the notion we need to test them with real users to see if they’re worth pursuing. Every piece of the project should have a purpose for some type of user or it’s just taking up time and space in the code. We test and iterate so we can be confident that we’re on the right path to a great final project.
From Design Thinking, we’ve taken the mandate to find empathy for the user. We incorporate the idea that a multi-disciplinary team will be more creative and we apply “human-centred design” principles to running our projects. This means we need to uncover the core values and goals of the users of whatever we create. We’re constantly trying to get inside the heads of these users and figure out what they want and what would make them feel successful. Empathy is probably the most important part of every project here at Lift. We want to feel what the users feel and really understand that they’re trying to get out of their experience. If we don’t have empathy, we just have assumptions. Nearly every project is worked on by a team and all of our opinions, experiences and ideas are valuable. We work hard to make sure the best ideas are always part of the project, and believe that those great ideas can come from anyone.
From the Toyota Way, we’ve “lifted” the name (see what I did there?) and the notion that anyone can stop the production line if they find a way to improve something. Anyone at Lift can help on any project and we’re constantly looking for ways to improve our projects. We engage a diverse set of team members on each project to leverage as many creative minds and perspectives as possible. If anyone thinks of a new feature or discovers a difficult issue, we confer with the client to figure out how this can be resolved. We may need to adjust the scope of the project or take away something less integral. Because everyone is a part of this process, we’re all looking for ways to eliminate waste or create new value.
From Rapid Application Development, we’ve borrowed the notion that everything needs to be thoroughly planned in advance. We know that the development process is fluid and that it’s likely that what we wanted at the start of the project will differ from what we end up with. However, we still need to plan out the schedule of development, which Lift folks will work on the project, what the milestones and key features are, and the specific tasks we need to complete. Our team knows we need to do enough planning and strategic thinking to get a comprehensive sense of the problem we’re solving and the value we’re creating. Everyone on the project participates in doing the planning. Developers plan out code modules and interactive elements, designers coordinate the needs of the brand and work on creating an awesome user experience. Our strategy team develops the personas and find comparable elements to help us figure out the breadth of the scope of the project.
We’re not really Agile, but we play one on TV. We don’t believe features are isolated—they’re part of a complex ecosystem of components. While user stories are helpful for focusing in on a feature, we need to keep our sights set on the broader vision. The Agile process has a bit too much emphasis on the individual features instead of taking a more holistic approach.
We’re not Waterfall. We organize all our efforts to minimize the number of spikes in effort throughout the project. We use our entire team throughout the project and organize our milestones to run concurrently. We do have deliverables that will slow down or halt progress if we don’t receive timely feedback and approval, but we minimize this issue by keeping in constant contact with our clients throughout. Also, we know we’re not in the business of creating deliverables, we’re in the business of solving problems or creating value.
We’re not Lean (unless you are). Actually, sometimes we are very lean but we know our clients are paying for a complete project, not an experiment. Lean project management tends to be directed only towards completing a successful project and doesn’t really incorporate the idea of a budget. Most of our clients have a budget they can’t ignore. Otherwise we try to use as many of the principles of the Lean project management process as possible.
We’re not “product management”, but we can be. For many of our clients, the project will be a product. Product management is a vastly different process, and while we do operate as product managers for some of our clients, we prefer to create long-term partnerships instead.
We’re not unstructured or informal. Our process might appear to be loose but it’s not. It allows us to continually produce good work and we stick to our guns in never allowing changes to the process itself.
Looking for more great reads? The following related articles might be helpful.
If you’d like to get in touch, please email Thorren and let him know how we can help with your project or question.