Guidelines for Embracing Project Unknowns

When I'm beginning a new project, that feeling of "I don't know what I'm doing" often creeps up in the back of my mind. The fear of encountering an issue that I won't be able to solve is unnerving, but I always tell myself that I'll figure it out. If I've figured things out this far, why should I have any issue with problems down the line?

This is a common fear for builders of software, so just know that you are not alone. Unknowns are practically unavoidable, given the project you are working on adds some foreign concept that you've never tackled before. Despite the feelings of fear, this is actually a good thing. When you push yourself beyond your current knowledge net, you have the opportunity to grow your skills immensely. Instead of trying to avoid these situations, embrace them. You will inevitably learn far more than you could have working on something you are 100% comfortable with. Of course, there is and should be a limit to this idea though, depending on the stakes involved.

Limits & Constraints

If you are working on a personal side-project, the idea of jumping into the complete unknown is a more palatable concept. When working on a client project however, a danger is introduced depending on the project scope and proposed technological boundaries/constraints of the project. As I said before, unknowns are unavoidable and should be embraced, but in the case of costing someone time and money, I'd recommend being aware of and enforcing a few parameters.

First off, rarely ever choose a technology that is 90%-100% foreign to you or your team when creating project scope. This can only introduce stress and tension between team members, especially if there is little-to-no time to learn to be able to build out the base-requirements for the project. A good rule of thumb is to have at-least one team member that is fully experienced in the proposed technology and foundation of the type of project to be the key consultant or "source-of-truth."  This will allow confidence in the initial project proposal process and when defining the functional requirements.

Second, always choose technology that is well documented and has a large community/knowledge-base surrounding it so that the possibilities of hitting impassible road-blocks can be more easily avoided. You never want to be working blindly on problems and coming up with solutions that work against the given framework. This can prevent you and your team from building something that is future-focused and can be easily handed-off to another team in the future.

Last but not least, if your team is put into a scenario of working with a 100% foreign technology, make sure that the client is aware and work to develop a launch effort that isn't tied to a specific calendar date. Giving a "window" of completion in these situations will always work better in the end, and will prevent pressure and impending burnout of your fellow team members. This window will be worked out with the client, but it may be a good idea to establish some sort of internal timeline that is separate to ensure motivation remains in place and everyone is on the same page. Being a team-member, you now have the flexibility of shifting this internal deadline as progress and efforts become more and more apparent, and communicating to the client as the window draws closer and closer.

TL;DR

Always make an attempt to embrace the unknowns of the project at hand. Figuring things out as you build will be one of the best teachers in your professional career, but do so with some constraint. Never, ever dive into a completely unknown technology for a client-project without a proven plan or a source-of-truth to consult when hitting inevitable roadblocks. Work to create a timeline that is flexible with all members involved so that milestones and progress can be communicated early on, and a window of completion can be established and narrowed-down as you go. If you find yourself being unable to find answers or a source to consult core questions when researching a technology, it might be best to change things up.