First Status Update - The show is officially on the road!

The show is officially on the road!

A few days ago, I got my first status report from my development team and gladly, we are making some progress.....I think!. This status report and the conversations leading up to it raised a few issues over the last few days.

The way the payment for the work is set-up, I pay my developers after they complete a few milestones. We had talked in passing about what "complete" meant for me but it never occurred to me to really stress that conversation until I saw the payment plan. One of my major goals is to not repeat one of the major mistakes I made the first two times I tried building this system. The mistake - pay for incomplete work. So while a development team may consider working code as "complete", a business owner typically needs more than working code to sell their product. Speaking specifically in my situation, I define complete as:

1. Working code/functionality deployed to the live environment ( i.e the site the end user is going to visit) and suitable for end user consumption.

• So if I am not comfortable showing the working functionality to my end users, either because the aesthetics is lacking for example, then the work is not done.

2. Technical documentation handed over.

• This is to ensure that should I need to fire the current development team, a new development team has some information to go off when trying to understand the system.

The other issue that came up was that I realized that I was not clear on what my expectations were from a status report. I assumed they read my minds, even though I had mentioned it in passing as well - I need to be able to verify the work you claim has been done, per the status report. In other words, I need a site to test out functionality that the development team reports as done. The first status report did not come with the ability for me to verify the work that was reported as done so I will have to stress my expectations in future conversations.

Day 1 (Again!)

Yesterday, I decided to REALLY take on re-starting this project for the 3^rd time –stop all the feet dragging, commit to developers etc. I have been working with a development team for a few months to discuss what a third attempt at greatness J would look like. Some of the key takeaways from the last few months were:

 

1.     Assessing the technical expertise of the development team: As a non-technical person myself, evaluating whether the development team (project manager, designer, developer and tester) has the technical skills to deliver the project has been a challenging experience. I don’t know what I do not know and I do not have the technical expertise to detect fraudulent development teams. Be that as it may, the development team I decided to go with this time around came highly recommended from a friend. In speaking to the team, they sound legit and their past projects give a good account of their work. However, the real taste will be in the eating.
 

2.     Finding the right fit between the development team and I: This one I am EXTREMELY picky about and I have the 6^th sense to spot teams that do not work the way I work. I am very big on communication………….VERY VERY BIG. As my dad says, most problems can be solved with dialogue. Fortunately, in communicating with the team over the last few months, I have been able to test their skills here. Though it has not been entirely smooth sailing, it has not been a disaster. I know the loop holes to watch for so I do not expect to have major issues in the communication department. I have already noticed improvements.

 

3.     Scope: The scariest word on the planet. This can mean everything and this can mean nothing. I’m typically very detail oriented so I was able to provide a detailed description (i.e business requirements) of what I needed to be done. However, as any sane development team will let you know, the amount of work may look simple or straight forward on the front end but when you get to the back end, it may be a different ball game. I do not have the technical expertise to write technical requirements so that was a down side in being able to quantify what needed to get done. This also impacted the ability of the team to come up with accurate schedule and cost figures. After some code analysis, we (the development team and I) all decided that we know as much as we can right now and there was no value add in trying to over learn the system up front (seeing as 2 development teams have worked on the code before now) when we can learn on the go. This approach does not always work but it made sense in this instance.

 

4.     Implementation: I originally planned to have one big bang release of the software after everything in scope was completed. After seeing the initial cost and schedule numbers, I freaked out then changed my mind. The new plan is to have 3 releases of the system, each release delivering a smaller piece of the total scope and building upon the previous release. This way I can get the product to the end user faster, gather feedback sooner and improve quicker.

 

5.     Availability: If there is anything I have learnt with my previous 2 attempts, it is that I need to be HANDS ON with the project regardless of the fact that I am not a developer. So in deciding whether to start the project immediately or in a few weeks, I had to look at my personal schedule. I have a full time job and I am trying to take a major exam in the next few weeks so now does not seem like the perfect time to work on this project. However, as one of my former managers told me, “there is never a perfect time for anything. Something else will always come up”. The timeline the development team provided for the project was longer than I had mentally planned for so rather than delay the project any longer, I decided to get started immediately. So with a good dose of time management and prayers, I am rolling my sleeves up and digging my heels in - there is never a perfect time for anything.

 

There are still some loose ends to tie but the major issues have been addressed and I am looking forward to getting started in the next few days.

Lesson # 1 - Focus on the customer!

Business ideas always evolve. You may start out wanting to build a small bungalow but end up building 4 blocks of flat. Based on my research, this is standard in business. As you learn more about your idea, product, investors, customers, employees, industry etc, you may need tweak your original idea to unanticipated needs.

This is why nothing seemed out of place to me when I started making modifications (largely additions) to my original business idea. I was paying obsessive attention to leaders in the Nigerian technology industry and start-up venture circles and making changes every time they suggested something new. In my mind, if I did not take their advice, I would end up making mistakes that would cost me dearly - after all they were the experts right?

WRONG!

These leaders and gurus knew their stuff. They explained what Business A did right and what Business B did wrong. They campaigned for the adoption of some innovative solutions. They brought light to some issues that a newbie entrepreneur may not consider.

While all of these are good stuff, no 2 businesses are the same. Different businesses have access to different funding amounts, investors, expertise etc.  As a result, what works for Business A will not necessarily work for Business B. So trying to implement everything the "experts" said ended up being a failure for me because I did not take into consideration the peculiarities of my own situation.

Most importantly, these handful of "experts" were not going constitute the majority of my customer base. As a result, they were not going to be paying clients. After having spent 3 years and LOADs of money trying to build the PERFECT system that could pound yam and wash clothes (jokes), I now realize that I should have started small, pushed the product out to the target audience to get some feedback and then make updates based on the feedback. I do not think that the "experts" were useless, I just should not have focused too much on them or taken their advice verbatim!

After all, the customer is always right!


"Lesson" series - This is in no way a prescription for how to do business or software development right. i do not have such expertise. I have been working on my web application and business for 3 years and counting and I am still yet to launch the application. This series documents the lessons I have learnt along the way.