Entrepreneurs have a unique approach, and sometimes that entrepreneurial mindset makes it difficult to effectively manage IT Projects. This is by no means is saying that entrepreneurs are lacking, rather the mindset is different than what is needed.
In this article, we will give you a basic understanding of IT Projects, and how to manage them like a boss.
An IT Project is any project that involves work with technical systems and typically lasts more than a week. For example, installing a new server probably is not considered an IT Project, but setting up a private cloud, is an example of an IT Project.
Projects also may include consultants and, or contractors to complete the project in a reasonable amount of time. For our purposes, we will be discussing software projects. This will include a new application to be developed, or major enhancements to an existing application.
All projects need a start date, a list of tasks to accomplish, and an end date. Pretty simple at a high level, but the difference between success and failure is in the details.
We have all heard how building a structure is the same as writing software, but guess what? That is a lie. The problem with this analogy is that a structure, whether it be a bridge, house or skyscraper, is a known object before construction has even started. Yes, there are some cases where delays are caused by unforeseen circumstances, but let’s take a look even deeper into the differences.
The planning for a single-story structure is different from the planning for a 100+ floor skyscraper. "But wait", you say, "Writing software for a single user system is much different than a million visitor a day website." True, but it’s much easier to scale an application than it is to increase the height of a building from 50 floors to 60. Planning from the ground up has to change for a difference in 10 floors.
Think of it this way. You have an idea. That brilliant, once in a lifetime, idea. It is going to change the world. This idea involves an app running on a tablet, or phone; any mobile device. It’s so good that everyone can use it, and they don’t even know they need it yet. How do you start? Do you start out building a system for 3 million concurrent users? But wait, it is a mobile app. Yes, but almost every mobile app connects to a server. Think of a game, you want the leader board, or in a shopping app you need the products for sale, or with a social networking app, there is the whole "social" aspect. All of that runs on a web server.
The answer is that you start small, and scale up as needed. This is where the construction analogy falls on its face. The better analogy is that writing software is like building an assembly line with multiple products with numerous variations. This is an entirely different beast. A living, growing, and sometimes shrinking factory.
It’s all rainbows, butterflies, and unicorns. Every project is a success, ahead of schedule and under budget.
There are many different statistics out there, but it looks like over 50% of software projects fail. "Super", you may be thinking, "Why would I want to start a new project?" I think the question you really need to ask is "How do we ensure success?"
There are three main issues with software projects:
"I want to build a mobile app." This is a requirement. A very vague requirement, but a requirement none the less. The requirements should describe the "what" instead of the "how"; leave the "how" to the development team. They will surprise you with creative solutions to the problem.
Requirements should be clear, concise, and approved by the team. Here is an example of a good requirement (in this case a user story).
"As a customer service representative (CSR), I want the ability to log in as a customer, so that I can make change changes to their account while I am on the phone with them."
In addition, there should be some acceptance criteria:
"I need X functionality in my app." For a moment, let us assume that X is a small enough feature to be able to adequately plan in the project. The team is working on X and making fantastic progress. Now, we should really include these other features that are super important.
"I need X, Y and Z functionality in my app." Wait a minute, how big are Y and Z? We only have a month left in the project. It is safe to assume that Y and Z are actually quite large. Adding features without consulting with the team first about the level of effort and future implications will cause issues.
Do not do this to your development team. Wait for the next release for those features.
"Our business serves X Type of customers, but now we are going to serve Y Type of customers."
This may be a valid and necessary pivot, but it may cause the project to be scrapped depending on the scope of the change. Pivot with caution.
Signs of a Healthy Project
Any good software project will use an iterative approach. The system should be delivered at the end of each iteration (even if it is only delivered internally to the team and management). Short iterations of two to three weeks are best. Any team that intends to deliver the project at the end of a 6-month development cycle is bound to miss some major pieces of the application or go down the wrong path. It is not that the team is incompetent, they may be the best in the industry, but without consistent direction from the business, it is difficult to meet the goals.
This is what we are after – momentum. Daily effort resulting in awesome software. Every developer should check-in their changes to the source control repository every day or so. Please tell me you are using a source control repository. We like Team Foundation Services with Git as the source control repository.
What does this mean, exactly? Here are some things you should see:
Here is what you should not see:
Want some more information specific to your organization? Drop us a line and we would love to dig deeper.