Today, we will talk about the subject of project artifact management.
The literal definition of artifact is a bit complicated. To put it in a popular way of speaking, artifacts are every aspects involved with project management. It involves lots of things.
As project managers, we have to choose the suitable artifacts base on the practical scenario. Meanwhile, we also have to actively use these artifacts on different stakeholders or team members, to ensure the effectiveness of the project work. In a word, the usage of project artifacts directly determines whether the project objectives can be achieved successfully or not.
It is very common that many new project managers are highly interested in some famous companies’ project management templates or methodologies which are floating around the internet. They hope that these templates can be used in their own practical projects, and hope that these templates can play roles as they can.
But in reality it is usually a total different story. It is more like “The foreign monk can not read well.” The root cause of this phenomenon is not because the external templates or methodologies are not good. It is usually because they have been misused. Most of these artifacts can not be copied as a hole to our cases, they have to be tailored accordingly first.
Just think about it, those templates or methodologies are extracted and concluded from those who have countless practical cases and experiences. They are what we call “general methodology or general theory”. But what about our single particular practical case? Can these general theory applied to our real cases or not?
1 A bad project experience
For the same group of people to do similar projects, we still have to consider the otherness and uniqueness between projects, not to speak of projects of different companies. Can the tools or methods of the time be used for this particular moment? The answer is not simply yes or no. The artifacts from former projects or other companies must be continuously altered and optimized accordingly in the process of our own projects. If we simply copy them to our projects, the projects will usually end badly.
Here is a negative case.
Last year, Oliver was working as project manager in a central enterprise of world’s top five hundred. He was in charge of an online service of O2O mode. The company breaks up the product lines into three main categories base on contents of services, and Oliver was working on a “To B” product line project. Oliver and business team were in Beijing, and a fraction of product users were in Beijing, but the majority of users are dispersed broadly around China. The product development was performed by a company of the same central enterprise, but in a different city other than Beijing. In a word, the project involved with multiple teams and many members dispersed in different regions of the country, which leads to complexity of communications and coordination.
Oliver was formerly in a famous IT company of China. He had worked as project manager and had succeeded many practical projects in his former company. At the beginning, the new company’s leaders and team members were very confident with him in charge of the new project.
Oliver brought the entire set of project management templates of his former company to the team members and train them. His business team had spent a lot of time on studying these templates. But when the team member was actually executing the project using only these templates, there came the problems. When the business team collecting requirements from their clients strictly following format of the templates, the business team complained about the difficulty of using the templates, and the clients complained about the business team because they did not understand their questions. At the mean time, Oliver and the requirement analyst both complained that the clients were low level and needed a lot of time for training and directing.
Meanwhile, the development team who was in a different city expressed that they could not understand the requirements and could not read the PRD. Everyday they called the business team for clarification of the requirements but only to be blamed. In the office of business team, these sentences were often to be heard in a phone call: “Why do you still have questions? It already has been clearly stated in the requirement files! It can not be more clear! Do what you guys should do, don’t change the requirements and do not ask so many questions, can you do that?”
At that moment, the project was stuck on the requirement analysis. After a few days of no progress, Oliver could not do anything but summoned all team members and clients to meet and discuss.
The problem was caused by the new project templates. Oliver and the team finally altered the new templates according to the characteristics of client’s requirements and developed a format which both development team and clients can understand easily. Then, Oliver re-trained all team members using the new templates and finally reach a common understanding.
2 A few thoughts on the case
There are a few thoughts and ideas can be concluded from the upper case.
First, directly adopting the artifacts from famous company without tailoring is a bad idea.
Some project managers only imitate the structure or formats of the project templates without thinking the purpose and meaning of the format, which would lead to bad results.
The reasonable action is to choose the suitable artifacts and tailor/modify them base on the uniqueness and characteristics of our projects.
Second, the inefficiency of project artifact management.
Without effective management on project artifacts, we can not guarantee the consistency of how various stakeholders use these artifacts and how they understand these artifacts. This scenario would cause the ineffectivity of communication and various complains.
Third, the most essential issue of artifact management is communication.
It is common sense that project manager should spend 90% of work time on communication. The important part of solving this problem is to develop a good communication management plan, which is apparently not being done in the upper case.
In summary, regarding to project artifacts, we need to tailor them according to our practical needs and use them with flexibility. Furthermore, we need to optimize them through the entire project life cycle, and communicate with the stakeholders using these artifacts to achieve transparency of project information. If any project manager can do these steps, the problems in the upper case can be avoided in our practical projects.