So you have an idea for the next killer dApp running on the Internet Computer (IC). Maybe you’re going it solo or you’ve teamed up with another software engineer or two. Small innovative teams are very common amidst a technology revolution. Many teams start out with nothing but an idea and a developer or two. Your team is high speed and low drag. It has all the right stuff for cranking out code, but do you have the right stuff for running a project that delivers a successful product? Do you need a project manager? Not necessarily, but to reduce risk and increase the chance of success you do need to integrate some project management fundamentals into the execution of your project.
I’m really excited about the IC revolution. As a technology leader, program/project manager, and IC investor I’d like to see as many projects as possible succeed. I hope to increase the number of successful product launches by sharing decades of knowledge about project success and failure. I’ve experienced both. As stated by Dr. Kerr L. White, “Good judgment comes from experience; experience comes from bad judgment.” My biggest lessons and personal development have almost always come at the cost of failure. However, I’d like to see you avoid failure.
“Good judgment comes from experience; experience comes from bad judgment.” - Dr. Kerr L. White
Over the coming months I’ll release a series of project success articles that can help your project succeed. I’ll cover some fundamental project management principles that you should consider for your project. I'll give you specific action items along the way. Whether you have a project manager or not these are principles that could make the difference between success and failure. In this article I'll give you eight high-level action items that will get you started down the path of success. Let's jump right in with Action Item #1.
Action Item #1: Identify a person on your team that will be responsible for project management.
According to the Project Management Institute’s 2020 Pulse of the Profession report, “organizations that undervalue project management as a strategic competency for driving change report an average of 67 percent more of their projects failing outright.” While the 2021 Pulse of the Profession report shows a general improvement in the trend of successful projects, globally only 55% of projects delivered the expected scope within budget and schedule. Project management fundamentals go a long way towards increasing your chance of success.
Development of your killer dApp is really a change management endeavor and successful change management requires a balance between people, process, and product. Throughout the series I'll use a change management framework that puts the focus on your people, processes, and product.
Change Management Framework
This includes the team that will bring your idea to market, the people that will benefit from it, and even the people that might oppose it. One of the main themes of the Internet Computer is it's enablement of decentralization. Decentralization is all about returning the power back to the people. Your project should infuse this focus on people into it's core principles.
We will explore the difference between leadership and management and why they are both important, but must be used in the proper context. It’s important to know when to lead and when to manage. Get those mixed up and your team is likely to be unhappy. I’ll discuss the importance of communication to both internal and external stakeholders and touch on some people specific risk management concepts.
Additionally, I will summarize the software development disciplines of project management, business analysis, architecture, development, and quality assurance with some discussion on successful interactions between them. While a team doesn’t have to have a dedicated person for each of the software development disciplines, it is important that each discipline is accounted for by someone on your team. Leave out one (or more) of the disciplines and it will show in your results.
Action Item #2: Create a list of the people on your project and what skills they bring to the team. Are all of the disciplines covered?
Process is how you choose to execute. This includes both micro and macro processes. Micro processes are steps you follow within your chosen life cycle methodology like user stories or code reviews. Macro processes are larger in nature and include the life cycle methodology you choose and how your micro processes fit together. While you don’t want to weigh your team down with process, no process at all can be just as disastrous. My philosophy with process (and software development in general) is to do the simplest thing that works and iterate on that.
Action Item #3: Make a list of the core processes that should be a part of your team's culture.
Product is not just about the product you intend to create, but also about the products, tools, and technologies you use along the way. Among other things, I’ll discuss product vision and scope definition as well as collaboration tools, quality control, and mitigation of technology risks via proof-of-concept development. I generally suggest that teams tackle the most difficult architecture and features first. That reduces the most amount of technical risk early in the project. When crunch time comes you want to be working on the simple things not the most architecturally significant things.
Action Item #4: Write a vision statement that clearly articulates what your long-term product objective is and the values that will help you deliver on the vision. Let this be a guide for you and your team.
When considering the proper balance between people, process, and product we will use the Agile Principles as a guide.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And, of course, no project management discussion would be complete without considering the four project constraints of budget, schedule, scope, and quality. Like people, process, and product, the four project constraints are interrelated and are like levers that can steer your project through the many unknowns along the way.
Even if you and your team are building sweat equity by donating your time, it is important to establish a budget. Regardless of how much time you volunteer there will be some costs to deliver a finished product. For example, you will eventually have to load your IC canister(s) with cycles and unless you get a Dfinity Developer Grant, that will cost. You may also find that some required skill sets or tools will have to be paid for. It’s important to know what most of your costs are ahead of time. You don't want to get to the end of your project to find out you don't have the money to get it across the finish line.
Action Item #5: Create a list of the biggest expenses that your project will have through to product launch.
In the IC technology revolution, time to market is an important consideration. It’s important to understand that all schedules are wrong, but some are useful. Schedules are simply models that help you manage expectations regarding how reasonable your target delivery period is given the work you have to do and the resources available for that work. I like to have multiple layers of schedules that are used for different purposes. A roadmap is useful for high-level product vision, a top-down or bottom-up project model is useful for understanding resource needs, and iteration or sprint plans keep you focused for short periods. Iteration or sprint plans are where the rubber hits the road and how you should monitor your velocity for future planning.
Action Item #6: Create a roadmap for your product's high-level capabilities.
Scope is the box that your product fits in. After product vision, the scope is the next layer of detail. Scope is then de-composed into requirements. Having written scope and requirements helps the team maintain a common set of expectations. Without scope and requirements you won't know when your project starts encountering scope creep which can kill a project with a thousand paper cuts. We will discuss different ways to manage requirements and how requirements are connected to every discipline within the software development life cycle.
Action Item #7: Make a list of what is in scope for your product and what is out of scope. Knowing what is out of scope is just as important as knowing what is in scope.
Many traditional project constraint models don’t include quality. While it is true that most stakeholders, especially external stakeholders expect the highest quality, project teams make decisions on a daily basis that either improve or reduce quality. Quality is absolutely another lever that is used, consciously or not, during product delivery. We will discuss both execution as well as product quality.
Action Item #8: Make a list of the ways that you will manage and monitor quality.
More to Come
I hope that this overview and eight action items add value to your project and increase your chance of success. We will dive deeper into the above areas in future articles. Over the coming months I’m looking forward to sharing decades of project management experience with the IC community in the hopes that it will increase the number of products brought to market. We will all benefit from a growing ecosystem of successful products.
I look forward to talking with you about project management. Shoot your questions my way. Until next time I wish you and your team the best of luck.
Technical Program & Project Manager, servant-leader, and backpacking adventurer. A believer in The Internet Computer and a max ICP staker. A lifelong computer nerd who is finding a renewed sense of purpose in the blockchain community.
Connect with @BrianGaller on Distrikt
Connect with @Brian_Galler on DSCVR
Follow @BrianKGaller on Twitter