#10. Client – Dev. Company workflow. Birds-eye view
Well, so far, we've managed to go through the Scrum framework, familiarize ourselves with the processes, the tools used, and the roles of the project participants. Now let's have a look at the cooperation between the client company and the software development company, and then we'll wrap up with a summary. That will complete the study of the "technical" aspects of IT management.
The purpose of this article is to get a clear idea of the structure of a software development company and how the company functions in general. Note, however, that, as in the other articles, what I'm describing here are the common practices. Bear in mind that individual companies may have their own peculiarities and that the structure, hierarchy, roles, and responsibilities of participants can differ dramatically.
First of all, let's deal with the terminology. A company that develops custom software for its clients is called an IT outsourcing company. The main (and usually the only) activity of such companies are outsourcing. IT outsourcing is a process whereby a company that needs to develop some software (but doesn't have the capability in-house) finds an outsourcing company and delegates this work to it.
For example, a financial and legal consulting company finds that because of its growth, it needs sophisticated software to help it manage its clients' data more conveniently. First, of course, it looks at the ready-packaged offers on the market, but then, after a while, it realizes that none of the available standard online/offline platforms can solve its problems. So the company drafts a document describing the functions that they would like to see in their software and send this document to many outsourcing companies. This document is usually called an RFP (Request For Proposal). As a rule, technical specialists are involved in its drafting to ensure that the requirements in the document are set out as competently as possible to avoid any confusion and delays.
Once the outsourcing companies receive the RFP, they begin their analysis and internal evaluation according to their own pre-designed process. They almost always have additional questions. Judge for yourself: we saw in a previous article how in one small user story, even a competent specialist can make a mistake. And here we're talking about tens or maybe hundreds of pages – a document which attempts to describe a huge with a myriad of different requirements. Obviously, no comparison to the single Story we'd looked at.
So, once the outsourcing company has listed all its questions, it sends them to the client. The client responds with clarifications, and, based on this, the outsourcing company completes its analysis and sends its proposal to the client.
The client, having received offers from a range of outsourcing companies, evaluates and selects the most appropriate one, the criteria being the price-time ratio. (Note that quality is not one of the evaluation criteria for the client since it is challenging to evaluate it objectively. So basically, you have to rely on the experience of those who have previous dealings with that outsourcing company in question. And as for using the outsourcing company's public portfolio as an evaluation tool, that's another story. Let's just say that relying on it can be very risky).
Next, the outsourcing company sends its Business Analyst to get a better understanding of the client's business. We have already talked about this in a previous article.
Here, from right to left, we see the CEO or COO of PlumbusSoft LLC, which is an IT outsourcing company.
The PM is accountable to the CEO/COO and is in constant contact with the Teamlead (and also, if there is one, the Business Analyst / Product Owner, who is independent/self-employed).
The Teamlead, in turn, coordinates the team, which, as a rule, consists of developers, designers, and testers. In some cases, one or several team members may work remotely. In this case, clearly, additional efforts in planning and coordination will be required (especially if the remote workers are in a different time zone).
On the left side, in the picture, we see the Product Owner (PO), who is an employee of the client's company and whose key responsibility is to coordinate the activities of the team working on the project and help with issues as they emerge. This coordination takes place using a previously negotiated protocol (Skype calls, chats, emails, co-writing Stories, and so on). The PO is always the person who has direct access to the senior management, direct customers of the product, end-users of the product, and all those whose help may be needed during the development process. In addition to all this, the PO has to have solid knowledge in IT so that they can differentiate between rational and redundant requirements. A major function of the PO is to make all key decisions on the product. In reality, finding a competent PO is really a very, very difficult task. Of course, we are talking about genuine quality, because a "certified" PO with a bunch of awards and reference letters is easily found☺.
Let's return to our picture. In most cases, an outsourcing company is engaged in many more than one project at a time. In such instances, companies often resort to savings, and so we have a situation something like this:
Such setups are used exclusively to save money. Team leads, like PMs, are an expensive resource. In addition to this, a PM working on just one project often has spare capacity, which the company uses, assigning him to work for two, three, or even more projects at a time. The Team leads, as a more limited resource, are usually assigned to one project as the main one and a couple of others in the role of consultant, however, again, I do not think this is optimal, although I have worked on 5+ projects simultaneously, playing a variety of roles (believe me, this is no fun and not to be recommended).
As the company grows, at some point, it may hire a Program Manager (PrM). More often, it simply promotes one of its PMs.
If the Project Manager is responsible for the progress, deadlines, budgets, and resources, then the Program Manager is responsible for the group of projects of the outsourcing company. His responsibilities include coordinating these projects so that their completion dates and budgets are consistent with the company's short-term and long-term goals. The Program Manager receives the reports from all PMs whose projects are in the PrM portfolio.
Take a look at an example of a simple but efficient setup.
Here, as we can see, the company has three major projects, and a Program Manager, who coordinates the PMs. The suffix "Web Division" is not accidental here. Many outsourcing companies provide a service in developing mobile applications. So, as the company expands, the structure evolves to include Program Managers of individual divisions who deal only with specific types of projects.
In this picture, we have added a Program Manager responsible for mobile application development projects. You may also notice a DevOps specialist who I forgot to add to the previous pictures. That's because DevOps specialists work lightning-fast and go unnoticed ☺.
In the last picture, we have added a few more roles. However, you will only find these in large, truly reputable companies, which may have hundreds or even thousands of employees.
When the company has a huge number of projects, the Senior Program Manager takes the stage. From the name, it becomes obvious that he is responsible for his younger brothers – the PrMs. He's the one who coordinates the major working areas of the company so that everything fits in with the goals set by top management. Directly above him are the COO (Chief Operating Officer), the CEO, and, in some cases, the company's partners and other key stakeholders of the company.
Now let's finish our analysis of the "technical" part of IT project management and summarize what we have learned.
First, I think it would be useful here to list what we covered and what we didn't so that you understand what fell outside the scope of this material but might be worth approaching other people to find out more.
OK, so here's what we didn't talk about – but I recommend you to read up (you don't need to go into details at first, just google and go):
What to google to become smarter:
- The most popular programming languages. Which languages are used for which types of applications;
- Who is the front-end, back-end and full-stack developer, and what is the difference between them;
- The key differences between junior, mid and senior about all the roles that I briefly described;
- Continuous integration, continuous delivery, and continuous deployment;
- The cost of developing applications in your local market as well as in foreign markets (usually indicated in man-hours);
- Even though in many books and articles on project management, you will often come across the concept of MVP (Minimal Viable Product), I deliberately skipped about it, because in my view, MVP is a term that has more to do with managing the product than the project.
What to read to become smarter:
- Mortimer Adler - How to read a book;
- Jonah Lehrer - How We Decide;
- Andrew Stellman - Learning Agile;
- Eli Goldratt - Theory of Constraints.
Finally, you can go through the Project Management Institute PMBOK (You can glance at this well of information with a dead weight in this ever-renewing book to know how books should not be composed.)
Well, as you see, I haven't recommended many books. This is because almost everything I read is not 100% related to management, while the books which are specifically about management, in my opinion, are poorly written and confusing ☹.
So, to recap, here's what we discussed and learned about:
- Projects, and how an idea becomes a project. In particular, we covered the following topics:
- The artifacts and features used in IT projects:
- User stories;
- The working environment of participants in IT projects and how to solve:
- The issue of coordination;
- The issue of communication;
- The issue of file sharing.
- The philosophies and methodologies of project management and the difference between these concepts, including the following:
- Definition of science;
- Definition of philosophy;
- Definition of methodology;
- Definition of a framework;
- The use of these definitions in IT projects;
- Use of frameworks
- Kanban method;
- Life cycles and approaches to software development and the differences between them:
- Predictable approach;
- Iterative approach;
- Incremental approach;
- Agile approach;
- Analysis of the principles of Agile.
- Working with the Scrum framework:
- Scrum Artifacts;
- Scrum Rituals;
- The roles of the project participants;
- Scrum role of project participants;
- Key values of Scrum.
- Scheme of acceptance and maintenance of the project. Contacts between the participants, and the various stages of the project;
- Requirements analysis;
- Development of primary documentation;
- Creating epics;
- Prioritizing epics;
- User stories;
- Evaluating user stories; explanation of velocity;
- Sprint Backlog;
- Retrospective analysis.
- User Stories: how they are composed and what they usually consist of
- Technical details that a manager should know:
- Intermediate servers;
- Testing, monitoring and analytics systems and why they are important
- Cooperation models between the client and the outsourcing company
For gaining basic knowledge, the material posted on this blog and in particular in these ten articles is more than enough. With this foundation, you can then go on to decide which books to read and, most importantly, you will understand from the very beginning exactly what knowledge you are developing and how it can be used in project management. If you have grasped this material well enough, at the very beginning of your career path, you will notice that many experts with years or even decades of experience do not understand the structure and operate with very simple, primitive and, often, erroneous concepts and ideas. The reason for this ignorance, I honestly believe, is our ego, which does not allow us to develop, and instead gives us an inflated opinion of our self. Our ego feeds us with small successes, stopping us from thinking about what we could have achieved if we had set ambitious goals for ourselves, and it is this awareness that has prompted me to write these articles.
Most of the books that you read would fit in a 30-60 page booklet. However, no author would have the modesty to acknowledge this reality; a pamphlet does not suit all the flourishes and obscure terms with which the author wants to show off his professionalism and deep knowledge of the subject.
Do not be fooled by this showing-off; instead, try to converse and stick with more ordinary people, with whom we have more in common.
This concludes the series of "technical" articles.
In the next article, I will talk about the career path of the manager and will give some tips which will always be relevant.