How standards affect the adoption of project management practices


In recent years, most software projects don’t do what the customer expected, and cost more than expected. However, we can change this situation by setting up a community or standards to find good project management practices. This could help to decrease the debates between different people. Standards includes both acknowledged parts which established by authority, and unacknowledged parts which produced by individual organization such as customers. Although it’s easy to set up standards, it’s still difficult to find good standards. Suzanne came up with an idea that “adopting the practices” [1]. It means with a series of practices, people could benefit from using them to learn them and apply them. Good standards can enable this adoption process and influence the adoption of project management practices in three areas: deployment of practices in an organization, customer-supplier relationships and the community of project management practitioners. So, it’s important to notice these three aspects. I think the first two areas are more important. I will mainly discuss them in the following sections.

Standardization and deploying the practice

When deploying a project management practice, a good standard could save the time. People develop the infrastructure by following a common reference point and have fewer debates. In reality, it’s not enough to just have one standard. Multiple standards could increase the competitive. To avoid the confusion and conflicts between different standards, some organizations adopt a principle of transparency. Some experts with different standards argue about which practices fit where and synthesize their ideas. This could help the organizations have better capacity to respond to the various external environments.

I really agree with this point. Standard provides a direction when developing a project management practice. Multiple standards could diversify the practices. However, to avoid the confusion, experts need to analyze thoroughly to come up with an organizational standard to respond to different environments. It’s very similar with the policy “One country, two systems”. In order to achieve the reunification of China, the leaders came up with this policy and allow Hong Kong, Macau and Taiwan to retain their capitalist economic and political systems, while the rest of China uses the socialist system [2]. Besides, there are also some autonomous areas like Tibet and Inner Mongolia. They govern themselves because they have different customs. I think it really a wise policy. Because China is a very big country, some areas have different history, economics systems and customs, the same standard for all the country may impede their development. So, I think good standard could reduce the time to deploy new practices and reduce arguments about which practices to focus on. However, if the organization’s scale is large and diverse, we need to consider multiple standards for different environments.

Standardization and customer-supplier relationships

In order to save time and find better suppliers, customer organizations always find a standard to evaluate suppliers and remove out suppliers who don’t meet their standards. I think it’s really a good way for customers to select suppliers they need, because it’s convenient and quick. However, Suzanne also pointed out the problems it may bring out. Some organizations don’t conform the standards well may regardless of their business goal or others.

Some years ago, there was a company called “SAN LU”. In order to increase the content of nitrogen, they mixed melamine into their milk powers. Milks powders with higher content of nitrogen could be sold in higher prices. However, melamine cannot be eaten. They thought they could not be revealed. However, this caused lots of infants dead.

So, don’t do this! Don’t struggle for adapting to the standard!

This is an exaggerated example. However, it does give us a warning. When developing the projects, we should concern more about the quality of products, or the technology used in the projects. Besides, customers should not over rely on standards or software process assessment, especially when they use outsourcing.

Standardization and practitioner community

There are some self-organizing and self-sustaining communities of practitioners. They help to evolve the field of practices they’re concentrating on. They aim to improve skill and knowledge in their field and affect the organizations to develop their project management standards. There are some worldwide project management communities of practice such as and PMI. Besides, ICPM [4] is another example of community. It’s an international community for project management. It provides an internet platform for people to discuss and keep up with what’s happening in the profession. So, as we can see, there are lots of communities for project management. It’s a good way for us to communicate with others from all over the world and improve the standards.


In this post, I discuss the how standards affect adoption of project management practices. Standards may affect the adoption of project management practice in three areas. We need to consider the deployment of practices, relationships between customer and supplier and the community of project management practitioners. All of them are related to the standards.



[1] How Standards Enable Adoption of Project Management Practice. S. Garcia. IEEE Software, September/October 2005.


[3] E. Wenger, Cultivating Communities of Practice: A Guide to Managing Knowledge, Harvard Business School Press, 2002.


Response to “Analysis eight secrets of the Software Measurement”


This is a response to the article “Analysis eight secrets of the Software Measurement” posted by s1301111 [1].

In this post [1], the author divides his article into seven sections based on the eight secrets mentioned in his referenced article [2]. The author talks about the eight secrets of software measurement by summarizing the referenced article and describing his experience and opinions. I think it might be a little bit longer and lack of a main point, so I think some sections could be cut off. This post will mainly discuss one point he mentioned in his article which I think is the most important secret of software measurement, that is “Both establishing and keeping a measurement program are hard”. For other sections he mentioned in his article, I’ll choose some and briefly demonstrate my points.

“It’s not about the metrics”

In this section, I think the main point he wanted to convey is that the measurement is not about the metrics. So, I think what are metrics is not very important, so it’s not necessary to use such a long paragraph to explain “metrics” and even demonstrate six principles to establish good metrics. I agree with his main point and think that what our final goal for the measurement program is, but not just regard it as a tool.

“Success comes from channeling an organization’s pain into action”

The author describes mainly in two parts. The first is that a strong motivation is important for improving and understanding the measurement. Besides, understanding the meaning and difficulty of software measurement is also a vital step for achieving the plan. I agree with his point. A strong motivation can give us strength to take actions. However, we also need to consider the difficulty before we take actions in case the measurement will quickly be found inappropriate.

“Both establishing and keeping a measurement program are hard”

In this section, the author demonstrates his points that both establishing and keeping a measurement program are very important and difficult. I agree with him, and I’ll focus on this section. When dealing with the measurement program, we need to pay attention to establishing and keeping. None of these two steps could be ignored.

1. Establishing

For the establishing step, we need to take some factors into consideration before defining a measurement program. Building an empirical model is very necessary, which means we must identify the technical, cultural, organizational, and business issue [3]. These involve both technical and business goals. I think the technical goal is essential and indispensable. Sometimes we just do a project at school but will not apply it to the market, so technical goal is the most important thing we need to considerate. We need to analyze the procedure and find some resources to define the method. For the company, they always overlook the importance of technical goal and ignore the business goal. However, to successfully establish a measurement program, developers need to first consider the goals in the context of the organization’s underlying business strategy [3]. Because the measurement program may be forced to stop due to lack of funding or have no profit. I think it’s similar with starting an entrepreneurial enterprise. We may come up with lots of entrepreneurial ideas, such us a transnational corporation, or just a small retail business selling some hand-made products. However, before we start, we need to consider if we can make profit, how to find funding, who are the customers and so on. Business goal is a very important factor and it’s really difficult to start due to lots of complicated and unexpected factors.

2. Keeping

After successfully establishing the measurement program, it’s also difficult to implement and sustain. We need to review the measurement program regularly, to ensure if it operates appropriately, and gradual program optimization [3]. If it does not meet the process made in early plan, we need to find the reasons, improve the program, or revise the plan considering the current state.

Other than the technical measurement, business is also an important factor for company to measure if they could continue. We should keep track of it gradually, to avoid the great loss. When I was in the university, there was a special study room that they aimed to give students a comfortable study environment. Because our study room and library closed very early in the evening, students always have no place to study. This company found the opportunity and set up a study room. It provided high speed WIFI, coffee, quiet rooms, group study rooms and so on. Especially, it opened all day. It was really a perfect place for students. We all came there, enjoying the comfortable environment during study. However, we never imagined that it forced to close after one year with nearly fifty thousand pounds loss. Because it supplied such really good conditions, it cost too much money. However, it mainly faced to students who have no ability to afford too much fee for study room. So they can’t make the fee too high and the profit can’t meet their cost. I think it was really a good plan, however, they didn’t keep track of the business state gradually and revise their plan, and finally they had to close the study room when they started to notice the great loss.


For other measurement secrets the author described in his article, I think he just agrees with the original article and doesn’t add something. As his article is a little bit long, I recommend that they could be cut off. To expend, I’ll now provide an additional secret of the software measurement which I think is important.

Measurement is being paid a lot attention from developers. However, it always be ignored by practitioners. However, the practitioners always trust empirical evidence of a measurement without its technical grounding. So, developers should communicate closely with them to understand the valid uses of a software measurement. [4] This gap should be paid more attention to.


In this article, I mainly discuss one key secret of software measurement that we should pay attention to the establishing and keeping a measurement program. In addition, I also give my opinion based on the author’s article that measurement is not about metrics and the motivation is very important, we also need to take it into actions. Finally, I provide an addition secret which I think is also very important that we need to bridge the gap between developers and practitioners.






Some new ideas for successful software management

Do you think software project is boring? Try to view it from another perspective!

When talking about software management, many people may think it involves high technology management or disciplined engineering management. However, Walker Royce, the vice president of IBM’s Worldwide Rational Service Organization, has given a new idea that software project managers are much easier to succeed if they regard their project as a movie production other than an engineering production. I felt doubtful and curious when I first saw this idea. However, when I read through the article, I think it’s really an original and rational idea that could be applied to the modern software management. I will elaborate some important elements that are vital for successful software management in the following sections.

So what are the important elements for successful software management?

In conventional wisdom, software managers may have many requirements for the project and his team. However, it’s probably the most misused word in the industry. In a software project, you can rarely see something is unchangeable. Plans, people, funding, milestones, designs and tests are all the component of the project. However, all of them may be change and negotiated at any time. So, the word “requirement” is improper to define or judge a project. Furthermore, the performance of software products could be measured by users’ perceived value. So, economics performance can help to prove if the software is successful or not. It’s pretty similar with movie productions. We can evaluate a movie by observing the feedback of viewers and the profits. So, in today’s modern software management, it just likes a movie industry. The qualified architects can be regarded as directors, analyst can be regarded as scriptwriters, and software engineers can be regarded as actors and so on. Especially, good project managers just like good movie producers. Furthermore, we can describe the modern software management as a discipline of software economics rather than software engineering. The software managers should make their everyday decisions like movie producers that based on human factors, macro-economic trends, technology trends, market strength and so on. In order to deal with these subjective decisions, Walker Royce recommended “using a steering leadership that compromise active management involvement and frequent course correction”. In addition, he came up with four patterns for successful steering. I will introduce and give my opinions about them.

Scope management

Walker Royce thinks that solutions and user specifications are evolved from each other. Because “requirement” is regard as a misused word which is mentioned earlier, he prefers to use the word “specification” instead. The first form of specification is the vision statement or user need, which could help to deal with the contract between the project development group and user or customer. The developer should use specific and formal format which might involve models or texts to make users understand the information. The second form of specification is not really similar with requirements. Walker Royce called them evaluation criteria. They are temporary steering targets not only from the vision statement but also from various other sources such as risk management analysis; architectural considerations; constraints of implementations and so on. I think Walker Royce really gave a proper revision for “requirements” in traditional software management. He has noted that the requirements are changeable, they receives a great deal of scrutiny because it always influences the contract between developer and users. Besides, I think he also noted the importance of “interim”, which could provide a better skeleton for early testing and give more accurate information for both developer and users especially for a risk management plan.

Process rigor

For most project managers, they would approve that the processes might be rigorous when the teams are distributed or the project is fall behind the lifecycle phases and so on. However, Walker Royce comes up with a distinctive idea of successful software development process that earlier phases center on realizing demonstrable functionality and later phases focus on robustness and performance of the product. Besides, the process rigor has equally important affect on teams. I really agree with his idea. The software development process is very similar with our assignment. Processors need to balance the various students and give proper deadline so that most of the student could hand in assignments with their maximum abilities. In addition, I think Walker Royce’s arrangement for the lifecycle phase is well-designed. It could help to give an appropriate plan in case wasting time or working too much in some lifecycle phases. Today, an improper focus on process rigor is the basic reason for software projects fail.

Process honesty

In the traditional development process, there are tremendous reasons may cause the developers and users don’t trust each other. However, most people may not concentrate on it although it is a very important factor during the process. Walker Royce finds this and he thinks trust is essential to steering and to keep a balance on users, developers and plans. I think trust is inconspicuous but very important. His idea recommends us pay more attention to a functional and usable product rather details of contract.

Quality control

Walker Royce considered that testing and testers become the first vital component in the progress. Every team should build test cases. The analysis team would find the peak data load or critical control scenario that lead to extreme cases. The design team would come up with a competitive model. The test team would build test cases and capture its response. I think testing is the key point among a project. We can build test and find the worst case. Besides, when testing, we can improve our project’s robustness. It can be simplified as programming, we need to consider as much conditions as we can in case the program may not succeed. To sum up, I think testing is indispensable.


As can be seen from above, good project manager is just like a good movie producer that not only develops good products but also helps to guide the less experienced team members. Furthermore, I think the steering leadership style raised by Walker Royce is an original and brilliant style for successful software management in modern. Not only can we create satisfied products, but also get economics benefits. In addition, I think Walker Royce really gives me a wider scope for software project. It could also be regarded as the construction of building and so on. He evokes me to think of the software project management from various perspectives, and it will not boring and hard when talking about software project any more. I’ll apply these new ideas to my future career.


1. Walker Royce, Successful Software Management Style: Steering and Balance, 2004

2. P. Graham, Hackers and Painters: Big Ideas from the Computer Age, O’Reilly, 2004.

3. Standish Group International, CHAOS Chronicles, 2004.

4. W.E. Royce, Software Project Management: A Unified Framework, Addison-Wesley Longman, 1998.

5. M. Cantor, Software Leadership, Addison-Wesley, 2002.

6. J. Marasco, The Software Development Edge: Essays on Managing Successful Projects, Addison-Wesley, 2005.

7. P. Kroll and P. Kruchten, The Rational Unified Process Made Easy: A Practitioner’s Guide, Addison-Wesley Longman, 2003.