#1. What is a project?
Project Management, as a concept, is so wide that any quick search online will give you a long list of books and articles with bestselling titles such as "Five Steps to Successful Management" or "Eight Books of Mandatory Readings for Beginning Project Managers." I personally find it hard to believe that reading bestselling "how-to" books will turn you into an irrefutable specialist on the subject. Articles, however, are another topic entirely.
It is my opinion that books are only helpful if you have a specific question that needs to be answered or a skill that you'd like to learn more about. Every profession has its basic set of skills and knowledge that should be obtained to become a competent professional in the field.
The framework for project management was first defined by Mr. Frederick Winslow Taylor in 1911. His book "The Principles of Scientific Management" outlines the qualitative changes that can be made if one uses their minds the way nature intended them to. You can read this book if you are interested in the origins of a scientific approach to management. Its tone might not be the most approachable, and it might not be the most politically correct book, according to our modern society. One would say that it might even be considered offensive in today's terms. In simple terms, the book is a collection of F. Taylor's observations of the problems the industry faced during his time. He outlines the specific issues that led to a more scientific approach or one that is based on a more common sense to rise over the blind belief in the correctness of the leadership of the era.
Now, let's get serious. Together, we will go through an overview of the entire project management cycle, starting from the initial abstract idea and ending with the reasoning of the correct appointment of the project starting date. Since each of these stepping stones towards proper project management is an entire field of research by itself, we will only concentrate on the general and most common concepts in the field.
We will discuss a software development IT project, be it a web portal or a mobile application, or something else, it does not matter.
IIdeas are links that we make in our minds between different events and observations. Ideas can vary a lot, but the main thing to bear in mind is that ideas arise in us for a reason. If at some point we had an idea and thought: "This is interesting," it means that it really WAS interesting for us – at least for that moment. We shouldn't discount ideas just because they are not attractive to others, or don't reflect public opinion or social values. Our brain is an infinitely beautiful mechanism, and any incoming thought may have value. So each new idea deserves our attention: do we develop it further, or forget it.
A good idea is valuable in the business world. It always comes down to finding an unmet need. So the question is: how do we find this need, and how can we formulate an idea?
The solution is quite simple: we need to bring together 1) an experienced software engineer (someone who can evaluate the technical feasibility of the idea), 2) a business analyst (whatever we call them, this is someone who understands both business and the mechanics of software development and can, therefore "translate" from business language to programmer language and vice versa), and 3) a specialist in any field. This Specialist could be anyone – a doctor, an architect, an artist, a photographer, or an existing business owner. And so we have an Analyst, an Engineer, and a Specialist.
A competent Analyst will analyze the workflows that the Specialist is dealing with, to understand how everything works, and then will look into the details and try to identify problem areas: those processes that need improvement. The next step is to understand whether the problems are common, affecting many people, and if that is the case, the Analyst will ask leading questions to the Specialist to verify his assumptions. Eventually, the analyst will have some draft notes on possible solutions, and will approach the Engineer to see if any of the identified solutions are feasible, and if so, how long could it take and how much will it cost. By the end of the conversation, the Engineer will already have a rough understanding of the future shape of the project. The Specialist will grasp how valuable this nascent project is and what fundamental changes it can lead to, and the Analyst's "homework" will be to verify the Specialist's statements.
Let's imagine that the Specialist owns a chain of restaurants. The Analyst has learned that there are problems because, during peak hours, the delivery trucks are stuck in traffic. The analyst suggests developing a mobile application for the Specialist, which will allow students to register in the app and to deliver food by bicycle, thus bypassing the traffic jams. The Engineer reckons the idea is not complicated, because the restaurant already has a system for registering orders, so it's just a question of transferring these orders to the common pool, from where students will be able to accept jobs on a "first in first out" principle and do the deliveries on a commission basis. The analyst does some more thought and proposes, after developing the project, to provide a cloned version (a kind of white label) to other restaurants for a percentage of each check. This pleases the Specialist, who is already anticipating his power and domination on the market. Meanwhile, Engineer is already thinking about the architecture of the application, and the Analyst is checking if there is anything similar on the market at the moment. End of story.
A vital point to note is that, at that very moment, when the meeting ended successfully, and the participants recognized there was progress, it was the analyst's written notes which comprised the nascent project. Everything that happened before that, all the discussions, these were simply ideas. At the moment when these ideas were outlined and noted down in draft: this became a project.
A scheme or diagram is an infographic that describes the links between different parts of an emerging project. Schemes are made to see the big picture and not lose focus. The only rule is that a scheme should be useful. No other rules – unless specified by the designer. If you're looking at the scheme you've drawn up and you don't see any specific benefit or added value - then something obviously went wrong☺.
It's not a good idea to include too much text in the diagram since separate documents can be drafted for this purpose. Thus, in the scheme, we set out only those common elements which can be said to be "equal" to each other. Sticking to this practice will keep your schemes neat.
For example, here is part of the scheme that I sketched at draw.io for a project of a hardware encryption device for mobile phones.
White color highlights the steps performed by the system; red: the questions that need to be clarified. Green is where everything is clear.
Again, we started off with the idea that evolved into a project draft. We described the project in the form of a scheme, to understand what questions we have, and to help us focus on what we should do next.
Unfortunately, when people talk about documents, they often refer only to papers that have some sort of legal value, thereby inflating this concept in proportion to their ego.
In reality, a document is simply an object (a file, or a physical object, as the case may be), which contains specific information. So I stress any file in which there is information that we recorded can be considered a document.
For example, when I need to solve the issues that I noted down in the above scheme, the solutions which I reach will be recorded in separate documents. One document will contain a description of the research that I conducted on some issue, and another one will include a list of the things required to solve problem X, which I identified in the diagram before.
Set out below is an example of the scheme and related documents:
You can go even further and create a sort of workspace on the web to share with your partners. For this, the perfect tool is Trello:
Here we opened a simple Kanban board. In it, we created two columns with pretentious names: General documentation, where we put our files and diagrams, and Upcoming meetings - a list of events of varying importance that we have to attend. After that, we add our colleagues and partners to the board, and voila: we're up and running, focused, and haven't missed a thing. One small detail not to be overlooked when creating a virtual workspace: indicate the dates of key events in the relevant card/ticket descriptions.
So now we have an idea that has become a project, plus a diagram with a general description of our workflow. We also have documents generated as this workflow progressed, and there is a working board in a web where all project participants can see the current status of tasks. It is important to emphasize once again: there are no rules in creating the boards, columns, and cards, other than the rules which you invent. For example, in the Trello board shown above, I use red labels to indicate ongoing tasks, and blue ones for those that are completed (I just love colors).
On to our next step:
A sketch is a visual representation of the raw version of our project, with a general description of the navigation logic and key components. I'll draw an example – here it is:
Sketches are needed in order to conduct a preliminary validation of how everything will be displayed and quickly share your thoughts with your partners.
Once the sketch is accepted, and agreement given to continue working in the direction indicated, we proceed to the next step: to create a layout.
Mockup - in essence, this is the same sketch, but with added styles, colors, and a much more attractive look. If a pen and paper are sufficient for the sketch, when it comes to the mockup, you will need specialized programs like Adobe set, etc.
As a result, we get this beautiful picture:
Depending on how much time we have and how low the probability that we’ll have to change key components of the layout, the next step could be prototyping.
Prototype - Basically, a set of mockups gathered together within the framework of a tool that enables interactivity. An example of applications that facilitate the smooth development of prototypes is InvisionApp and MarvelApp.
Interactivity in the prototype means that you can click on different image buttons that take you to the next page. This is very convenient for the user. In fact, as I said, the prototype is just a collection of pictures. Obviously, the prototype is not functional, because we haven't written a single line of code yet. Still, the more precise the prototype is assembled, the easier it will be to understand what needs to be changed and what doesn't, and the earlier it will be possible to finish assembly of the final design.
Approved UI Design
The next step after creating a prototype is to wait for its approval by authorized persons. We may have to redesign the prototype many times while the customer clarifies the requirements (or we explain the design to our client ☺).
After approval of the design, we proceed to the next step:
Software design, or the design of the project architecture
In this stage, the leading developer responsible for the project describes how the system should operate at all levels. The description includes which servers are responsible for what, which APIs are used, and how and what data is transmitted.
Since each project’s architecture is unique and depends on a huge number of parameters, we won’t go into detail.
Once the architecture of the project is clear, the team informs its management about the timing and estimated cost of project implementation. The management, in turn, examines the conclusions and forwards them to the client.
Project planning deadlines
After we have agreed on the price and other terms, we draw up a calendar along the lines of the following:
- Jan 22, 2019 – Kick-off
- Feb 18, 2019 – DEMO
- March 8, 2019 - DEMO
- April 9, 2019 - DEMO
- May 25, 2019 - DEMO
- June 30, 2019 – Project launch
- August 15, 2019 – Stats review
The contract is signed and January 22, 2019, is the kick-off date or, in simple terms, the date when we begin technical development of the project:
We have now gone through the whole cycle, starting from the idea and ending with the start date of project development. We think you'll agree there's nothing too taxing in this logical progression for a person who can think structurally: everything fits into place.
It is essential to understand that each element is only valuable if it has a practical purpose. I have seen dozens of projects in which there was no documentation at all. I have seen projects that went straight to the prototyping level, bypassing mockups, and sketches. In fact, there are even companies that go straight from the sketch to product development. And although the document which describes the architecture of the project can be extremely important, in fact, it is ignored in the overwhelming majority of cases if the project only lasts a few months.
What I've set out above is the correct way of doing things, but it's not a dogma, and if necessary, you can do it as you see fit, as long as you do not lose focus and know your next steps.
So now we know what a project is and what the constituent stages are.
In the next article, we will discuss the concepts which developers deal with when working on the project. In particular, we'll introduce EPIC, User Story, Task, Sub-Task, and Bug.