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.
WHAT IS AN IT PROJECT?
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.
WHY CONSTRUCTION ANALOGIES DO NOT WORK
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.
WHAT RUNNING IT PROJECTS REALLY LOOK LIKE
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:
Poor Requirements
“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:
- CSR can select a customer to impersonate
- All data is displayed just as if the customer is logged in
- CSR can make changes to the customer account
- Etc. You get the idea
Changing Scope
“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.
New Business Directives / Pivot
“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
Iterative Approach
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.
Good Momentum
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.
Highly Functioning Team
What does this mean, exactly? Here are some things you should see:
- Effective communication between team members
- Team members who have pride in their work
- Kudos and credit are given to those who have earned it
- Transparency with the business
Here is what you should not see:
- Arguing, fighting and major disagreements
- Isolationism
- The blame game
START THE CONVERSATION
Want some more information specific to your organization? Contact us and we would love to dig deeper.
Check out our website. https://frontrangesystems.com/
For similar topics subscribe to our newsletter. Subscribe on LinkedIn