A Top MBA Graduate’s Experience with Software Development.
My first computer was a Vic20 console (similar to the Commodore 64). It took cartridges as well as had a tape drive. As there was only one game, the only way I could play different games was to purchase a big 1000 page games coding book. For hours I would copy lines of code and save the progress to cassette tapes. You don’t know coding frustration until you have completed 2000 lines of code and the program doesn’t work, though it did teach me the skill of debugging. So from the age of eight, I was coding. This continued into my teens where I learned C++ and started developing my own little games. You have never seen a version of Pong like the one I made. Throughout my career I continued to code, particularly focusing on Excel and Microsoft, using it’s background version of Visual Basic to make some pretty fancy documents.
While I have always enjoyed coding, most of my career has been involved in dis-related fields, such as commercial cleaning, manufacturing, security, property etc. I have run countless projects and almost always achieved really good results.
Following the completion of the MBA program in 2014 I was very keen to return to the world of software development. I did exceptionally well in my MBA, graduating top of my class, and having learned all sorts of project management skills.
When I walked into my first major software project, these skills were effectively thrown out the door. The classical method of project management, with Gantt charts, milestones and deadlines does not translate to software development, in fact, they are liable to lead one down a garden path into trouble and failures.
Despite all of my years of experience in project management, and my MBA credentials, what quickly became apparent is that software development is a beast unto itself, requiring its own set of skills and methodologies to achieve success.
There are fundamentally major differences between a project developing a web application and a project for building a home. When building a home, the technologies, methodologies and skills required have been developed over many years and differ little from one project to the next. A plumber coming in to plumb up a home will apply the same skills and techniques from one job to another. While the layout of pipes will change from house to house, the skills he has acquired over the years will apply in practically every situation.
When developing a software project you are effectively building something brand new every time. While there are similarities from one project to another, overwhelmingly new technologies are required in each case. And given the speed of technological development in software, a new project may have you working with an API or framework you have not seen before. What it means from a practical perspective is, that standard Gantt charts and project management methodologies will lead to project failure.
While I had been exposed to Agile Project Management in the past, I always thought it was a flash in the pan sort of technique. Something that would be gone in the next five years and everyone would return to classical project management.
Well, it only took about two weeks to be thoroughly disabused of this idea! It became clear fast that Agile, while not perfect, was the most workable method available in software development.
My key learnings over my first 6 months, which I now apply religiously, would be worth considering by stakeholders when undertaking a new software project.
1. Accurate estimates are practically impossible.
Given the nature of software development, generalised estimates can be made, I don’t think it is possible to deliver an accurate estimate. And this is where Agile development is so essential. In software development Scope, Time and Budget are not equal. At the outset of a project the team must decide which is the most important element. If Scope definitely cannot change, then Time and Budget must be flexible. Likewise, if Budget is completely fixed, Scope must be malleable. These three items are constantly competing which is why an Agile approach is mandatory.
2. Change is inevitable.
Very rarely have I seen a software project where Scope has remained fixed from the outset of the project. Despite the best efforts of many people to develop a fully detailed, unchanging scope document, the reality is it is extremely difficult to conceive of all eventualities and it’s only when people begin to see the site coming together they realise that certain elements won’t work or need to be changed.
As a project manager on software projects I have no issue with change, as long as stakeholders realise that they many need to increase budget or decrease the scope somewhere else.
3. Test, test, test all the time
Under traditional project management, the entire project would be completed and then testing would get underway. Sometimes, this is done at major milestones as in construction. In software development thorough testing must commence from day one. This includes the developer, but even more importantly the client. It is the client who will best understand how the site will be used when completed. So as each new feature is developed and pushed to the staging (testing) site, this feature should be thoroughly tested.
It is too late to leave testing to the last minute, as I saw with one project where the stakeholders were just giving each feature a quick two minutes check, signing off on it and then left major testing to the last minute. It was too late, and features they had previously said were working were found not to be what they actually wanted.
So while my MBA was an incredibly valuable experience, there was a new technique of Project Management I had to learn to make software development work. If these three points above are understood and applied by you and your dev team and all stakeholders, you are much more likely to achieve high levels of success.
Don’t fall into the trap of trying to fit inadequate methodologies to software management, it’s just going to make your life really difficult.
