Does every member of your team know where your project is going?
It is said that there is no point in re-inventing the wheel, an object we are all familiar with and use in our lives. So there is no particular need to think up something new. But the question is, using the wheel metaphor just as an example, is the object you are creating really the proverbial wheel? Or does the end result sometimes resemble a crooked wheel? When does a wheel end up as a crooked wheel, and how do you avoid such a problem? Do your team members know that they have created a crooked wheel, or does everyone think that they are producing a wheel?
In a way, this issue can be applied to virtually all branches of activity. In everyday communication, on which side do things become bogged down, and where do messages fail to reach their recipients? And when do such problems arise? Can they be effectively eliminated, and can we learn lessons from recent history? Naturally, there is no single answer, but we can attempt to address the issue by taking a closer look.
Project management and web integration
It is the project manager who should always know whether the team is creating a wheel or a crooked wheel. Above all, it is in his/her interest to continually sort and update information to be able to respond appropriately to superiors or subordinates. Of course, situations occur that cannot be covered by a process, and it is good to prevent them. Below we mention some checkpoint items to help you safely avoid lots of such unnecessary work. How to further deal with the information is the responsibility of the project manager. In certain situations, it would seem that a checkpoint would be the work of the QA team, but this is not so. The checkpoint does not go into such detail as testing; rather it is mainly about a quick comparison of input and output information between various phases of the production process. Using the checkpoint basically eliminates the “dead letter syndrome“, i.e. when your input is a square and the output a rectangle.
Due to its complexity, web integration goes beyond the standard “start – manufacture – launch” steps. Thus, the demands made on the processes connected to a particular project are different from “ordinary” demands. Project management in web integration includes the coordination of various sectors and types of work, as well as different subjects that can operate completely independently of each other. Choosing the wrong process leads to a constant loop of improvements/adjustments, not to mention an excessive amount of needless work.
Processes, diagrams, rules and guidelines…
All properly functioning organisations have, in varying degrees of detail, “how to” guidelines for their business area. Naturally, it is desirable that such information is available in a coherent and up-to-date form, so that everyone can find it and make use of it, if needed.
Over time, individual explanations of particulars processes emerge. This essentially involves repeated behaviour, which results from a certain type of automisation and as activities are mastered. One of the many small deviations in the process is the “because that’s the way it worked before“ approach, which goes hand in hand with “I don’t need to tell anybody again“. This happens especially in the case of experienced “matadors“, who do the same thing repeatedly, perfecting it. Thus, a set of rules is no longer particularly useful for them. Naturally sometimes they forget to consider others, who may not be familiar with their approach, do not have a crystal ball and are not expecting any deviations from the known processes.
This is standard development and evolution, but it is important not to forget the golden rule: COMMUNICATION, even in seemingly minor issues, because we can see that what seems trivial to one person may not be so to another.
Repeat, and train your staff!
Repetition is the mother of learning. Do not be scared to set aside time every so often for meetings where key people can brush up on “how we do things” and “why we do things“, even if they should know such things. Interesting opinions can emerge at subsequent meetings and can be taken into account. Meetings with a particular focus and aimed at a specific project phase and process – beginning, evaluation and repetition – prove that interesting opinions are shared. You can read out more about this issue and others in a separate article.
What is a checkpoint and how do we set it correctly?
Is it a comprehensive output document produced by a responsible person in a particular section, or can it can be a 10-minute chat over coffee or lunch? Of course, what form it takes is up to each individual, and frankly it is not the most important issue. What is important is the contribution it makes. Depending on the management methodology, these points are given different names, but basically they involve a control mechanism helping aim whole system to right direction.. It is, of course, preferable to always check a number of smaller parts of the project than the entire project when it finishes.
It is typical for projects to go on for more than a year, and in such cases, when there is no checkpoint, nobody will be able to remember what was there at the beginning and what should be there at the end. Not only does timing play a role in the project, but also the client, who during the process will have many comments and make changes and suggestions.
It is also good to use a checkpoint when work is being quickly assigned for a further period and for the period until the next checkpoint. Confirmation of more work is always desirable in view of project length and the proverbial light at the end of the tunnel.
Get all your staff involved in the process!
The process comprises various pieces of information and procedures that should be observed to achieve the correct result. In a hierarchical company the processes are divided accordingly. Sometimes, of course, this can be problem because the left hand does not know what the right hand is doing. To a large extent, this is because some people treat the project as their own and see it only as human resources for a particular task, and fail to see the bigger picture. It is useful to explain to everyone how a project will influence something or someone, and how the project is important for the staff involved in the final stage of the process.
Discuss project matters with your team members and give them the space to share their views. Devoting twenty minutes of your time to staff members interested in the project can result in a payback of a several fold increase in proactivity and engagement among staff.
Clear proof of such benefits can be seen when a particular checkpoint is the responsibility of a person in a department connected to the controls being carried out. Doing so ensures two very important things. The first aspect is personal interest in the project, and opportunities to comment on or influence the project. These are motivating factors for many people. The second aspect is personal responsibility for work and the assurance that the right semi-finished product will be delivered for the next part of the process.
Project conclusion with your team
In all cases, after the project is completed, there should be some form of conclusion. We use the “Lessons learned” meeting, to stress positive and the negative features of the project. Ideally, the meeting should involve the team leader and staff members, so that everyone is clear about what they should pay attention to in future and what was done properly. It is very important to make both sides of information available and not only the negative. Negative meetings have a poisonous impact on everyone, and key people often take away only the lessons to be learned (e.g. “next time I will keep my mouth shout“), which is wrong. The end of the project should never be seen as an excuse to criticise those who caused the project to falter along the way. Yes, you should mention such problems but do not name names. Those directly involved in the issues should be informed and those who are not should beware of familiar issues arising in future.
All negative information should be adequately balanced with positive information.
There is no universal rule, only general recommendations. Do not be scared to give information to your colleagues. It is better to repeat information than not to say it all, as somebody may need to know this information. Learn and share interesting information with those around you. Take an interest in what others are doing, even if it is not your area. The more you do so, you will better be able to come up with a solution with an application, which is always helpful.
Most important tip: Learn to admit your mistakes and learn from them!
Have you developed checkpoints along the way?
This is an apparently simple question, and for most people in production the answer is yes. Every process relies to a certain extent on reverse controls, but the question is how often and how in-depth should they be? The checkpoint is an important step any manufacturing process and should not be overlooked. It is just not enough to say, “we are producing a blue square“ at the beginning of the process and leave it that until the launch. Sometimes along the way our blue square can turn into a light-blue rectangle. If we lack appropriate checkpoints for a light-blue rectangle, we will be in for a shock on the launch day. In addition, quality control itself (testing) could be, with the wrong output, evaluated as a light-blue rectangle as functional and thus seen as completely in order.
Of course, every project will require something different, but to give you an idea of how we do things here at Lundegaard, here is a description of five checkpoints, the bare minimum for small and medium-sized web projects.
- First: project beginning
Here the “big picture” of the project should be presented to the team. It is important that everybody has a stake in the project, knows what their tasks are, and how their small component fits into the overall scheme of things.
- Second: concept completion/wireframe
The business assignment usually tends to generally be clear. Naturally, however, it is not fully detailed, and so it is helpful to make comparisons with the original assignment to identify any differences.
- Third: after completion and comments on graphic design
Very often during the web page design process minor differences emerge from the approved wireframe (due to either technical or creative reasons). It is also often the case the client makes notes on the graphic designs, and in a way this can have a negative impact on them, since the client does not pay attention to the wireframe, but the result
- Fourth/Fifth: coherent programme units
These checkpoints can be linked to a QA project. Essentially, this is not about testing functionality but ensuring that the concept is in line with the assignment.
- Six: project conclusion
This is an important part of the project, and for team members, it provides the final perspective on the overall work. Information about all positive and negative situations is made available, with questions such as is the client satisfied, where did the work falter, and was it an invaluable experience for every person in the project team?
Together with the beginning, this point is essentially the most important in terms of further training, development and involvement of people in the project team.
More complex projects require a more flexible approach and also more checkpoints, since staff at the “production line“ will frequently not see the start or the end of the project as a whole, and a need arises to make them aware of it and inspect it. Often a programmer sees a complex system in terms of small components and needs a more global view of the whole project! If they are unaware of the context, it can appear to them (sometimes they are completely correct) that the solution designed for their component is unnecessarily complicated, or inappropriate. They will therefore do things their own way. Without a checkpoint, you will not be aware that the small components are not working together.
The regularity of project management does not let up, and you will thus become aware of small component incompatibility at the least appropriate moment...