Natalia Fedorova, Regional Coordinator

27 August 2020

What is Project Management in IT

While middle management positions are quite exhausting and hectic, a Project Management job in IT is nothing like that. Here, you get to talk with clients, closely interact with your team, and solve challenges along the way.

Project Management Work

Unless other duties are attached, all your work day consists of, well, project management. Software development projects feature 5 distinct stages, and there’s enough for you to do on each of them. This is a solid mix of variety and stability: you get to do different things while not jumping too much. The industry standard is to have one project manager locked to a single project.

A key difference between the conservative idea of management and project management in IT is the timeline. A mobile carrier or some other post-industrial economy company does not really have an end point to their business (unless they go bankrupt that is). When it comes to software development, you can define the start and often the finish. Don’t take the latter literally: even when you stop developing new features, your team or someone else will have to maintain the product.

Project Management Phases


Initiation is where you and a potential customer decide if your company will be doing the project in the first place. Based on previous communication/client information/brief, a project management and the customer explore and set up initial boundaries. They may include the scope of the project (one app or an ecosystem around it), workforce and financial resources required, and the end results (is it a Minimum Viable Product or a market-ready solution?). 

Having answered those questions, a project management comes up with a proposal and sends it to the client. It may take further negotiations but, once the proposal is approved, the project moves to the next stage.

Requirement Gathering

Once both the client and the team are in principle committed to the project, it’s time to further define it by requirement gathering. “Build me an online clothing store” could seem enough on the customer’s side, but that’s just on the surface. If you don’t discuss size grids and coupons functionality, there will be frustration if you put too much effort into something irrelevant or neglected key functionality. 

An important section of requirements would be design limitations. They are not necessarily about visual design: design limitations here mean constraints on how your team will be meeting project requirements. For example, some companies may be reluctant to share personal data of European clients with specialists outside of the EU. That would lock you out of utilizing a regular Data Science freelancer from the US and force you to find someone in Europe.


I find planning the most interesting aspect of Project Management, but then again, I don’t work there. During this phase, you define the budget and then sit down with your team to discuss the timeline. Requirements are broken down into tasks, tasks are grouped into sprints that last one or two weeks, potential risks are identified to be monitored throughout the project. 

Another important distinction to make here is the Scrum vs Kanban approach. In short, the former indeed breaks down projects into sprints while the latter merely identifies whether a task is backlogged, needs doing (“to do”), in progress, requires validation, or done. Usually, modern software development projects are a mix: you want to be both defining smaller scopes of work and tracking progress of tasks.


Implementation is when your team starts working on the product. Regular team members do their magic, freelancers come and go to do their part, everyone is excited and hopeful. Normally, you don’t simply bury yourself into work before the product is finished. Teams have daily standups to discuss what’s going on and weekly demos to help stakeholders (Project Manager, Product Owner) and colleagues track the progress.

This is what you hopefully prevented with solid planning

Like hinted at earlier, planning does not really end with planning. During the implementation, you may have to switch tasks around to meet unexpected circumstances or account for excessive/insufficient time allocation. 


Once the end-product is ready (if the result is indeed a product and not R&D findings), it would eventually be rolled out or shipped to individual customers. From there, somebody will have to keep the product operational, eliminate bugs, solve design/implementation blunders that the team and the client could not spot at first. Some products may be built with the plan or at least possibility to add features later. Continuous delivery and continuous deployment, where new functionality is added in short cycles without interrupting core operations, are becoming increasingly popular. 

If a solution is low-maintenance or the client has their own IT department, your team may stick around on a retainer for a month to address immediate issues. After that, you will be handing everything over and the product will remain with the client on maintenance. Alternatively, your team will be the ones continuing to fix and improve the product. A popular delivery model, Software as a Service, implies that clients simply use your existing software in exchange for licensing (and maintenance) fees. Thus, the project never really ends.

Project Management Prospects

Career prospects in Project Management are pretty clear. You go from a project coordinator to managing your own project to managing a group of projects. Depending on the size of the company, you may become the main person responsible for project delivery across one and/or multiple units of the company. Some horizontal mobility into management (and potentially COO) positions is also an option.