Ever since the early days of my career as a project manager, I have enjoyed reading tutorials and good practice manuals on how to best organize the work processes. I believe it is important to know exactly which are the steps needed to complete a given work process, so as to ensure it is finished, functional and profitable.
It’s an everyday challenge to adjust the processes just the right way so that they bring the wished-for results, and, more importantly, how to communicate those adjustments and organizational processes to colleagues.
In this post, I will introduce the practices used at Studio Present. The guidelines compiled below are aimed at seasoned PMs, junior PMs and of course, the clients. As we all know, the learning process is never-ending. Even today, with more than 15 years’ experience under my belt, I am still learning from experienced leaders, investors, and PMs.
This decade and a half spent working in this field have made me confident enough so that now I am able to transfer some of my knowledge to the younger generation of project managers or perhaps help someone upgrade their processes.
So, let’s begin. There is always that famous first email or phone call, which triggers the cooperation and leads to the:
Initial meeting
I always advocate that the first meeting must be in person. If for whatever reason, this is not possible, then the meeting should be held via video call.
Face expressions and body language are crucial factors for smooth communication and better understanding. After all, you don’t want any misunderstandings, especially not at this vital, first stage of cooperation.
At the first meeting, we try to gather as much information as possible: about the company, stakeholders, and the desired application. What is it exactly that the clients want to achieve or improve? What is the current problem that they want to solve with our support, by creating this new application?
How will the application help in generating more profit or in decreasing costs?
So, after the initial goals have been laid out, we move on to the second part of the meeting, which is the presentation of our company. We must carefully present what our rules and processes are, what the flow of the production is and what our expectations are. Please, make sure the client understands your company’s guidelines, so as to avoid later misconceptions.
At the end of the meeting we must find out about the main idea of the application, its basic functionality, though without getting into much detail, there will be plenty of time for that later.
If the project is to have several stages (and let’s be honest, most projects do), then we need to know roughly what these stages are. For example, if the client wants an app for managing warehouses, but he already knows that in the future, the app should be connected to the CRM software, then sharing this piece of information would be a good idea, as it will assist our overall work and result in a better app.
At the meeting, it is important to be able to devote all our attention to the client. In this regard, I’ve been in the habit of recording our conversations during the meeting, naturally, only given the client’s permission. However, an audio recording is an immensely helpful tool when it comes to preparing the:
Technical documentation and diagrams
When creating complex web applications, I always ask the company to assign one or more people to work closely with us and stay in constant communication. It is simply impossible to develop good technical documentation and lay solid groundwork without this.
In most cases, the documentation is prepared with the help of Google Docs. This way I can create first draft titles and subtitles, sections, everything starting from the first meeting, incorporating all my previous experience.
Google Docs is shared with the client only for viewing and commenting.
It also makes it easier to see the comments and quickly receive answers to my questions that arise during the writing process, although email is also an option.
If the client does not have any documentation, this means that I will have to take on the role of lead writer, with the client providing me with the vital data. At the stage, I start posing questions to my senior team.
If the app development is complex and there are numerous references, the best way is to draw diagrams. When I have visuals, it is much easier to explain to the team or to the client how the specific items need to function. With the diagram, we can all see the main blocks of the application and their interrelations.
For diagrams and wireframes, I usually use Axure RP because of its great sharing capabilities.
Offer for producing wireframe and UI/UX design
Due to app complexity and uncertainty, for the last couple of months, we have been opting for a new workflow.
Before offering a rough estimation for the entire app development, we first create a wireframe and app design (prototype).
Based on earlier jobs and previous experience, we can easily predict how much time the given project will require.
Once we have finished the design, both the client and my colleagues can see the big picture. Compared to simple diagrams, these visualizations with their details can provide us with a much better understanding as to whether a specific feature needs to be removed or some other feature added instead.
Wireframe
This is the phase when we are starting to create the skeleton of the web application.
Based on the documentation, diagrams, and priorities, we create a wireframe, sometimes this may even be a clickable prototype.
Every page which is to collect some input data or pull some data from the database is created with the utmost care.
In this process, we also welcome any form of contribution from the clients, as it gives us invaluable feedback and confirmation that all the fields and requirements are in place. This is a crucial part because in this process we make a point of enlightening the clients, i.e. teaching them that sharing their time and knowledge is of great importance.
The wireframe is a rough sketch, without any design elements so our attention can be focused only on the basic functionality.
This is the time in the process, when most of the time, the first changes happen, as compared to the initial technical documentation.
Design UX / UI
As soon as the wireframe is approved, the designer can then start to prepare the future design.
This is the step when we select the relevant colors, fonts, app “voice”, specific to the devices where the app will be most in use.
It is crucial is to pay attention to the particular user niche (age, gender, job type...), i.e. what target group this app is aimed at.
When several of the pages have been designed, we again bring the client to the table for discussions. At this stage we invite the client to provide feedback, we also change certain setups, add or remove options.
For most people, it is hard to imagine the final result based purely on the written documentation because it seems too abstract or too technical… However, once they see the designed elements, it suddenly becomes visual and therefore also easy to react to it.
For the design presentation, we have developed our internal platform. It is something like a client profile page, where we store all the designed pages, versions, and wireframes for a certain project. In this section, the client can have a separate library for logos or other assets for later use.
Sometimes we start with the mobile design, sometimes with the desktop design, mostly depending on app usage.
During this process, the designer can produce a logo and other brand materials, such as pictograms.
How many people need to work on a given project?
As soon as we have the project documentation, wireframe, and design, I can present the project to the senior developers. This gives me the chance to lay out the big picture for the project and point out the possible pain points.
My job is to help and isolate the parts which we have never created before because we need to calculate the time for research. The senior developers are key factors in this process.
We discuss the technology to be used and the way the app will be developed.
The frontend and backend developers will also add their comments, so at the end of this meeting, we are 80% sure how much people are actually needed for completing this project and what kind of tasks can be done by our junior programmers.
Now we can inform the client about when we can reasonably start with the coding process of the app.
Offer for developing a web app
By this stage, we have all the information necessary to make an initial offer to the client.
For the last 3 years, most of our projects have involved creating complex web applications. We usually opt for working using the Agile method with Scrum or Kanban elements. This means that our main goal is to deliver MVP as fast as possible, to see how well it performs and also to have early feedback.
We allow the client to make changes in the application during the development time. My job is to explain to the client what will be different after the current change.
How will these changes be reflected in time/price and functionality?
This flexibility has one “flaw”. The project price cannot be fixed. The price given in the initial offer is purely for information purposes and in 99% of the cases, it will be higher.
It is completely normal that the client does not know what he or she will need in the future (or cannot know before seeing it in action). What’s more, the developers cannot predict every single step in the developing process. It is impossible to estimate time accurately when the app in question is so complex.
Even given our combined experience of 50 years, we always face some unpredictable situations or challenges.
The discussion with the client is again a crucial element at this stage. We present the various options, which may include abandoning of certain function for MVP version or transferring some tasks to the next development phase.
Frequent and honest communication entails mutual respect between the client and the agency and this is vital for completing the project. In this process we strive to have a long-lasting business relationship.
Depending on project complexity, we offer multiple levels for maintenance packages:
Maintenance includes:
- Monthly site checkup
- Maintaining server and services on it
- Security updates
- Quick response to ongoing issues
When the client agrees to the maintenance agreement, this means practically that the client books our time and ensures that we will act immediately.
Contract
Personal agreements and handshakes are more important to us than real contracts. Still, there are certain rules in the business world that must be respected, such as signing a contract.
Our contract is written in plain language, without overly complicated lawyer talk. It explains the rights and obligations of both parties.
During Studio Present’s life (since 2006), we have never had legal problems, a fact we are extremely proud of.
There have been situations where we had disagreements with the client because it turned out we had different goals. In these cases, it’s always better to cut the cooperation early on.
Setting tasks and user stories
Studio Present is divided into several teams:
- Project managers
- Designers
- Sitebuilders
- Backend developers
- Frontend developers
- QA team
- Server team
- Team for content
- Digital marketing
The team managers and team members are responsible for creating the tasks and we discuss the right time to start. So how does the process work? For example, the QA team does not have anything to do before the programmers finish their work. The sequences are carefully coordinated to make the entire work process run smoothly.
During the creation of one task, we estimate the time needed to develop certain functionality. Sometimes the larger tasks are divided into smaller ones and frequently we are forced to make priorities. We often are faced with some problematic issue that was not previously visible or known, requiring a prompt reaction.
The senior staff are crucial at this stage because their experience provides vital information on how much time will be consumed or what the pain points are that will likely take more time to sort out.
When this planning process is completed, we have a more realistic time estimate for app development.
Team “kick-off” meeting
It’s time to bring all the team to one table and once more talk through the entire concept of the app.
However, apart from this initial meeting, there are regular short briefings on what the main goals are.
We go through every task and perform additional adjustments as necessary. This is the time where we choose our priorities for the first two weeks of development.
The senior programmers are left with the task of providing additional explanations to junior developers.
This is also an opportunity to identify the new challenges connected to the given project and work out the possible solutions.
Preparing the development environment
Our colleague responsible for the server side needs to make a local copy of the CMS, so that every developer can pull it and start to work.
The version control system is configured, which means that the client can start to follow the progress of the app development on the developer domain.
However, it is important to note that sharing the app development process at such an early stage is only possible if the client is somewhat technically educated.
Sitebuild & Frontend
Sitebuilder - the man who is building the foundations of an application
Their task is to create the basic fields, content types, regions, blocks, views for frontend developers and backend programmers.
After several days of sitebuilding works, the rest of the team can start to work on the application itself.
The frontend developers are in charge of transferring the design to the working product. They also develop the dynamics and user experience with CSS and JS in constant cooperation with the designer.
Examples:
- The sitebuilder creates all the fields for entering data, configures basic modules that will be in use, configures basic site settings…
- The frontend developer sets the general application style which is defined by the design. The task is to make typography rules, the type of buttons, and define the style of all the HTML elements that will be in use.
Programming
First and foremost, we must make sure that the programmer has understood the task at hand.
The next step is to create a database scheme, in order to see what the relations and keys are.
When some functionality is done, we can present it to the client on the test domain. This gives the client a chance to test whether everything works like it is supposed to. For example, the client needs to check if the formula used to calculate the shipping price based on weight is correct.
In this phase the entire design does not need to be ready. This is the beauty of Agile development where we can test isolated functionality at this early stage.
One of the most common tasks for programmers is to create the connection of the app to the third-party applications. This is done through API and can be related to CRM software, ERP, or Newsletter system, among others.
Static content
When we are creating a web application the content is not seen as a crucial element that must be dealt with from the very beginning.
However, by the time of testing particular functionalities, it might be required to have the content uploaded in the app.
Some examples for static content:
- Demo products
- Pricelists
- Team members
- Store locations
- ...
Quality Assurance
According to our contract all of our employees must do a QA for their tasks.
The project manager will test some parts of the applications.
Our QA team tests the entire work of the developers and designers.
We believe that the best approach is to have fourth link in this process, which this is a person from the client’s company. A new pair of eyes can sometimes spot issues that have gone undetected up until then, giving a chance for the development team to react.
The combination of all this checking means that we already have a functioning and well-tested application. The ultimate confirmation that everything is working as it should will come from users of application.
Live server (production)
Once we have confirmation that the system is working seamlessly and every bug has been fixed, we start with the process of transferring the data to the public server.
From this moment on the application is connected to the real domain and everyone can access the application.
The server administrator configures the SSL (https) certificate, emails and we enter the real data, such as for credit card payments, for example.
Maintenance
Assuming that the goal is for the app or website to run smoothly in the foreseeable future, it is necessary to come to an arrangement with the client regarding some form of maintenance package.
In theory, creating a stable system is straightforward. However, there are many factors that can mess with even the best developer sites and cause the failure of the application.
We strongly recommend that our clients get covered with a technical contract for this part so that they can ask for support for eventual repairs.
If the business is healthy, then, apart from maintenance, there will always be room for improvements of the app. With this maintenance package you as a client have in effect reserved our time for fixes and upgrades.
Upgrades and new features
Let me follow up on this last sentence. In most cases the online business is rapidly changing almost on a daily basis. New services appear with a need for some new automation and because of these, you need to upgrade your web presence or application.
The current practice at Studio Present is to talk to the clients about their plans for the future: what do they want to develop in the next two weeks.
The client can change the priorities and have insights into all the work we are doing. This level of transparency is good because the client can act immediately when there is some show stopper or when we need certain data or information to continue with the task.
Of course, we make sure that we keep our client in the loop and offer advice on what, in our experience, would be a good strategy.
By this stage of app development the client and Studio Present have gotten to know each other well and this “work marriage” can continue to grow naturally.
Marketing
Sometimes your business and your app is one of a kind and you are like monopolist but eventually there will be similar services and will have to fight for your share. This means that some kind of marketing must be included.
At Studio Present we have a strong marketing section which is in charge of the digital presence of your company, brand or app. You can find out more about our marketing approaches at official site.
https://www.studiopresent.com
When meeting with the client, we bring in the marketing team because they can help to define:
- which are the core values that we need to promote
- what we need to emphasize on the new site
- harmonization, focus on needs of business owners and their customers.
The second case when the marketing team’s involvement is invaluable is when we need to redevelop some old site / project. The marketing team can point out the technical needs for better promotion activities, based on the analysis of history data. The team’s input will tell us how to optimize the site for social media, particular users or search engines.
Payments
I know that discussing invoicing and money are usually off limit topics. Still, I’d like to explain to you how we operate.
If the application is complex, the client will be sent an invoice for the technical documentation.
The second invoice will be for the wireframe and design based on the work hours.
When we have determined the estimate of the project, the client must pay a third of that amount in advance.
The following month we prepare the invoices for the previous month, also time-based.
Conclusion
Now you see our current work process. In our experience, every 6 months or sooner something is likely to change or needs to be upgraded. Just like in any other branch, constant changes are inevitable in IT business.
We keep telling our clients: don’t be scared of changes, promote them among your colleagues, and explain to them why something is better in this new way. When we explain to the client why some alterations are necessary or when you present some change to your colleagues, generally there is a better percentage of acceptance.
Sometimes, changes may prolong the development time but in return, you will receive a more stable product and much better quality.