Before anything starts, we have to take a realistic look at the given proposal or project.  While everyday I wish I was floating around in my flying hydrogen powered car or being able to teleport instantly to a vacation home on a terraformed mars, these things, in the present reality, are just pie-in-the-sky dreams.

There are many times when products or projects fail before they even start.  Improper allocation of resources, unobtainable goals or just a lack of time are just as guilty in destroying ideas as bad execution.  Whether it be working in start-ups or big corporations, the bottom line is that we’re working with human beings. To be human is to err, and in the context of feasibility, to err sometimes means not having enough foresight to plan properly for success.

Constraints

Budget
Budget is usually the first barrier that surrounds a project or proposal. With a limited amount of funding, budgeting a project is more crucial to start-up businesses than larger companies. From my own experiences while start-ups have limited budgets, enforcing it doesn’t happen as much as it should.

My career started at a start-up. Everything was new to me, my first taste of office life, the first time I was making a salary and financially independent. I worked extremely hard at that first job, I’m sure many can empathize with that, learning but also trying to work up in the ranks. In a company of about 30 people I became the sole designer. I had no predecessor and I had no mentor, prior to my arrival, the executive team hired a third-party marketing firm for $300,000 to come up with a logo. The money was spent and they weren’t happy with any of the proposals. When I came along, I spent 2 weeks with the executive team, they liked the logo I created and we went with it. At that time, I was only part time and on an hourly wage ($20/hr), so after everything, the company spent $301,600 on a logo that should have only costed $1,600.

So what was the point of this brief and highly undetailed story? Well it tells us that you can get good results at the right price as long as the right questions are being asked and also that poor budget planning can be very costly. Eventually the company went belly up due to a number of reasons but the biggest reason, to no surprise, was it ran out of funding, sound familiar?

Human Resources
This is not talking about the department that deals with hiring people. This is getting people with the right skillsets for the right job. In my experiences, a project becomes infinitely harder when corners are cut for getting the right person. When there is a large or complex project, all the cogs, big or small need to be turning smoothly, when one falters the whole machine stops. The consequences of not having the right people on a team was never apparent to me until I saw how crippling it could be to a project.

We all work hard, right? Where we lack in knowledge or experience we make up with research and studying. In a previous project I was on, budget was tight and we had to get a few more developers on the team to move the project forward. Finding the right people was a challenge and when my managers got desperate, they started to let things slide. Eventually the “developers” that we got weren’t actually developers. A few people were moved internally from other positions to development positions and they were learning on the job. The fault of this became apparent as the project timeline moved along but no progress was being made on the product. We were working in an agile environment and at the end of each sprint, our newly appointed developers would have no results to show and always asked for extensions. Sadly, while everyone else on the team was able to perform their jobs on time, the project couldn’t continue, leaving everyone very frustrated and demoralized. While everything else was seemingly ok, one cog didn’t spin properly and it led to a complete system failure.

Scope of Work
This is the “don’t bite off more than you can chew” section. A combination of understanding project requirements, budget and available resources will outline the scope of work needed for a project and from that, manage the timeline and deliverables of a project.

In the enterprise software world, our projects revolve around customer requests. I go out with a team of colleagues to understand what the customer wants, their challenges, pain points and other things so that we may build a solution that addresses all these things. Our responsibility is to provide the customer with the best value to address as many of their needs as possible, given the constraints on budget, scope and timeline. More often than not, our customers want to get as much out of the project as possible, and rightfully so. In the situations where new requirements are added after the initial assessment and estimations, we get “scope creep” and it’s something we try to avoid. This messes with our resources, our timeline, pretty much everything. It happens so often that, in order to control the scope of a project, we first try to establish a minimum viable product (MVP), meaning that we first build a solution that has all the essentials to function and then once the MVP is established, tack on all the nice to have features. It’s an important part of my job and the solution architect’s job to understand from the customer what is a “need to have” versus a “nice to have”. In an agile environment, understanding and gathering this information is crucial to laying out the scope of work that will be needed throughout the whole project.

Timelines and Timing
A project’s timeline and timing are two separate significant aspects of a project that converge on a point. An estimated timeline of a project gives the team an idea of when the project will be concluded as well as giving the team timeline breakdowns. In agile, sprints could be days, weeks or months and the duration of the project will be determined by how many sprints there are. This is, obviously, essential to the management of a project but it’s also important to note that it provides us an idea of when the product or project will launch. The timing of the launch is the convergence point of how timelines and timing relate in the context of feasibility.

In a given project, I might be given a few days or a few weeks to complete my task. Anyone that has done any kind of “abstract” work will know that time doesn’t flow linear, sometimes you get inspired and work fast, sometimes nothing comes to you. Regardless of how short or long of a notice I’m given, I know that the project as a whole still needs to go on because timelines are usually set for a reason. While I wasn’t part of the project that I’m about to talk about, it reminds me of the importance of timing and how things can go wrong if ignored.

The project was for a product that would provide a new revenue stream in an existing competitive market for the company. It was fast tracked and almost unlimited resources were provided to see it through. About 200 people were allocated or hired to work on this project that had an initial timeline of 6 months. Six months became almost a year and one month prior to the estimated launch date, a competitor released an almost identical product to the market, a market where they already had an existing foothold and customer base. Needless to say, almost overnight the project was shut down, the personnel laid off and the project, that had cost millions, dumped in the trash. So while this was unfortunate, the saving grace from this project was a lesson that timelines and the timing of an idea needs to be strategic and well thought through.

Methodologies

Agile
The flip side of managing a project to ensure its success after the planning, is the execution part. In the agile methodology model, the process can be broken down into 3 main phases, definition, exploration and materialization.

Going in logical order, to start a project, we must first understand what we’re doing. In the definition phase, this is where all the fact gathering and brainstorming begins. This is also the phase where we must empathize with our stakeholders and the demographic we’re trying to target, researching, understanding, ideating and performing design thinking exercises. It’s here were we start to formulate pictures in the cloud and go back and forth to tune our thoughts and understanding

After we’ve got a good understanding of our demographics and the landscape they’re in, we begin to explore how to conceptualize these ideas into prototypes and apply design principles to the matured prototypes. Our thoughts are now becoming more clear, we’re all on the same page and we have something tangible to judge.

Then it’s time to materialize our understanding and concepts. This is where we take the prototypes and put them into the hands of the people who will actually make our ideas and prototypes into actual products. In this materialization phase, here is where the sprints begin, the project is implemented and developed in small chunks. Within each sprint, we have sprint cycles managed by SCRUM masters and product owners to ensure the quality of the work and constantly looking for roadblocks and backlog items that might need to be re-prioritized.

Within the definition and exploration phases, a lot of back and forth can happen, as it’s meant to. This ensures that there is less rework later on down the road. In the materializing phase, the constant checks and daily SCRUM meetings ensures that the development process is smooth and the stakeholders are aligned. This is all to create more efficiency and higher quality products that align with stakeholder and end user requirements. The some caveats in an agile environment include very defined roles, preferably a collocated team, very strong communications and solid leadership.

Waterfall
Waterfall is a bit of an older methodology in the development world. In a nutshell, all the requirements are gathered in the beginning of the project then people are off doing what they need to do. Once things are done, people get together at the end to present the work and that is that. While most companies are shifting over to agile, this methodology does have its merits depending on the team composition. Waterfall works great if team members don’t have regular access to each other and the stakeholders or end users don’t have the time to review the work at the end of each sprint. Waterfall also doesn’t require a SCRUM master or product owner, though there are probably similar counterparts in waterfall projects. In the end, this methodology might be becoming obsolete due to advancing communication technologies, but it shouldn’t be completely discounted. To each their own.