And There are two brilliant episodes about Six Thinking Hats, just check ’em out.
由于回来之后加入了一个敏捷社区，机缘巧合下发现了这个课程。课程一共20讲，一共用时20天。这20天对于我来说其实增加了不少焦虑感，每天的固定安排是1.复习PRINCE2 Agile，2.阅读The Lean Startup，3.观看Development That Pays的视频，4.学习这门课。感到抱歉的是没有多余的精力看一些额外感兴趣的书了，原因应该就是那份增加的焦虑。比起其它三个的学习，这么课程对我来说可以算是每天的放松环节，说实话它并没有给我带来过多的新的知识，而是将我之前所经历的所学的简单并系统地进行串联，但是受益匪浅。
一提到PMP，我总想拿此与PRINCE2做比较。曾经看过网上有人回答为何PRINCE2在国内水土不服，而PMP却扩展迅速，他把原因归咎于国内企业的管理方式上。单从这两种框架的结构上比较（只是从现在看来，还没系统地学习PMP，可能之后的观点就不一样了），PMP主要以围绕PM为中心开展的项目理论，而PRINCE2中PM的角色出于中间层，他的权利来自于其上层的Project Board的授权，对上需要接受Project Board对项目的指导，对下需要直接管理项目。相比之下PRINCE2对项目经理之上的角色做了系统的定义，因此对应的权利和责任也有了明确的划分。PMP把需要管理的领域区分地更为细致，而PRINCE2通过将过程分割成多个stage来完成阶段性的管理工作。不过在我现在这个阶段还暂时无法完整地回答为什么在中国PMP更有优势这个问题。
相比于之前在学校以及准备考证的过程中的理论学习，这个课程更贴近实际工作，无论是在硬技能和软实力的介绍中雷老师都用到工作当中实际的例子进行说明和解释。从这些直观的故事中第一个感受就是原来项目管理如此简单，原来工作中所发生的问题都不是困难。这种错觉时常发生，就像读完The Lean Startup后就可以完美创业，读完The Practice of Management之后就可以掌控一家企业，读完Das Kapital就可以领导无产阶级大革命一样自负。可很显然的是，当然不行。存在这些错觉的真正原因在于，并没有尝试过将学到的理论和技能应用实际。雷老师有一讲专门提到了这个问题，掌握知识只是第一步而已。
To build a productive and enjoyable working environment.
How to make a choice between “doing the right things” and “doing things right” is an interesting topic people would like to discuss. In a nutshell, “doing the right things” focuses on defining visions, whereas “doing things right” focuses on the process of implementing the visions. Obviously, there are strong relationship and coherence between these two conditions. However, most articles around this topic assess and evaluate them respectively, instead of critical discussing. In other words, these articles emphasise the importance of one of them, while the view of taking less consideration on another also be implied. Such biases often exist in companies or project teams.
The Youtuber Development That Pays has presented a straightforward and specific situation when discussing the quality of code and the business value of a software product. He analogies the business objectives as a barrier on the way to success, and treats the software product as a ladder for crossing the barrier. In this manner, two potential results can be foreseen. A product with elegant code quality (or good design) may lead to “certain death”. Conversely, a product with not so good or even well-crafted quality may bring “untold riches” in a correct direction.
On the positive side, firstly, he has proved the importance of visions in business. As Peter Drucker wrote in The Practice of Management, visions could be analogised as compasses for navigation at sea. Only if setting the target, then the ship can move towards the correct destination without being affected by unexpected factors from environments. Secondly, the creator of the episode has clarified the priorities of different roles in a company or project from the perspective of software developers and market managers. A developer is responsible for the quality of products. And a marketing manager needs to find ways to improve the value of products in markets.
But I do not agree with the way of presenting this situation showed in the episode in order to the reason that “better ladder” and “more value” should not be compared as two independent sides. It would lead to ambiguity in understanding, as long as there is an explicit vision, the goal can be achieved by comparatively appropriate approaches or processes. This means that this idea may suggest people reduce or even neglect the requirements for one of them when choosing another side. Basically, this point is about how to make a choice between “doing the right things” and “doing things right” as well. In other words, the answer showed in the episode is “I am doing the right thing, while I’m doing it not so well, but it’s ok!”
The main cause is there is no unique vision. Drucker believes that human groups must be based on common beliefs, and must use common principles to symbolise everyone’s cohesion. Otherwise, the organisation will be paralysed and unable to function, and employees cannot work hard to get the performance they deserve. For a company or a project team, the “right things”, as well as the overall visions, must be identified clearly. Then, it is necessary to successfully express these visions to each employee, such as writing the visions on a large board and pasting them on the wall (like Kanban board). It could help the employees or team members grasp what value they can contribute by their work. So that employees in different positions not only simply pursue the “right things” determined by their responsibilities, but also contribute to the overall visions. The cases of software products are much more complicated than described above in practice. If the market manager focuses on profiting from the market simply and ignores product quality, or developers only care about code quality or product quality as “right things” in their minds, neither the overall nor the independent visions can be achieved then. This is also an inevitable result of not having a unique overall vision. From this perspective, if the “right things” are not set correctly, companies or project teams cannot do the “things right” then.
As mentioned above, “doing things right” has equal importance as “doing the right things”. First of all, it should be clear that companies or projects should create visions accordingly, that is, to determine which ‘things’ are ‘right’. Due to various factors from the marketplace, economic environment and so forth, that would bring uncertainties, there is no effective approach to verify that the visions are appropriate when creating them. The results would emerge from the market in the future only.
Drucker also supports this perspective and he suggests that economic and technological development lengthens the intervals required to verify the effectiveness of decision-making and its success continuously. Therefore, selecting appropriate methods or processes would help the organization to inspect visions and reduce risks constantly. I suppose it coincides with agile’s mindset.
In conclusion, I believe that “doing the right things” and “doing things right” play the identically important roles in management. The manager should demonstrate the visions of the organisation to each member explicitly and comprehensively. And everyone inside the organisation should keep them in mind and take responsibility for contributing to the visions, just “doing them right”. In addition, “doing things right” is an efficient and effective way to assess if the “things” are “right”. However, it would be meaningless without visions, even though there is the most effective working process.
关于如何在”doing the right things”和”doing things right”做出选择，一直是大家乐于讨论的一个话题。用另一个更简单的方式来说，”doing the right things”指的是对确立目标的思考，即为”what”，”doing things right”则为实现目标的方式的判断，即”how”。显而易见的是，这两个问题具有顺序性且关联紧密。但是，多数围绕这个话题的文章都把这两种情况分开讨论，而不是对其辩证思考。或者说，它们的确侧重强调了其中一方的重要性，可在读者眼里看来，同样带来了弱化对另一方的重视。更糟糕的是，这种偏见经常存在于公司或者项目团队中。
Development That Pays 在讨论代码质量和商业目的时描述了一个直接且特殊的情况。他将商业需求类比成通往成功过程中的一个壁垒，用于跨越这个壁垒的梯子则是软件产品。其特殊性表现在，它描述了一种即使具有优雅的代码质量（或者说优秀的产品设计），却导致”certain death”情况。相反的，一个代码质量不高的产品只要方向正确，最终达成了”untold riches”。
但我不认同的是他对于这种情况的表达方式，主要原因在于并不应该将”better ladder”和”more value”作为对立项进行比较。这将会导致出现理解上的歧义，认为只要方向正确，即使使用的方法或者途径并不理想，也可以实现目标。这就意味着他的答案正引导读者在做出选择时必定要舍弃或者降低对另外一方的要求。从本质上来看，这个表达方式就是在” doing the right things”和”doing things right”之间的硬性选择。换句话说，他的答案就是” I am doing the right thing, while I’ll do not so well, but it’s ok!”。这显然不是正确的。
导致这种情况的主要原因是在于没有统一的目标。德鲁克认为“人的团体必须以共同的信念为基础，必须用共同的原则来象征大家的凝聚力。否则组织就会瘫痪而无法运作，无法要求成员努力投入，获得应有的绩效”。对于一个公司和项目的”right things”，也就是目标必须明确。并且，需要将这一整体的目标成功传递给每个员工，比如把企业或者项目目标写在一张大纸上并且贴在最显眼的墙上，让公司员工或者项目成员熟知他们的工作将会帮助整个公司或者项目实现什么样的价值。从而让处于不同岗位的员工不只是单纯追求其职责所决定的”right things”，而是将这些标准服务于整体的目标。关于软件产品的案例在实际中远远没有上面描述的那么简单，若市场经理一味追求从市场中获利这个目标而忽视产品质量，或者开发者只把代码质量或者产品质量作为他们心中的”right things”的话，那么无论整体的还是独立的目标都无法实现。这也是没有统一整体目标的必然结果。从这个角度来看，如果没有正确设定统一的”right things”的话，那么一个公司或者项目团队也不可能做到”doing the things right”.
当然，我们不可否认”doing things right”的意义。首先必须要明确的是，公司和项目需要有根据地设定目标，也就是预估哪些things是right。由于来自市场环境、经济发展等多方面因素导致未来的不确定性，导致没有办法保证预设的目标是否正确，只有通过市场的检验才能知道答案。德鲁克同样证实了这一观点，他认为经济和技术进步使证实决策的成效和收获成功所需的时间不断延长。因此，选择合适的恰当的方法或者手段将会使通过预设目标的航线线路更加顺畅，从而有利于组织不断检查目标，减少风险。我想这跟agile的思想不谋而合。
因此，我的观点是：在团队管理中，” doing the right things”和”doing things right”不管对于任何角色而言都具有相同的重要性。管理者需要将组织整体的目标传递给每一位成员，并且每位成员的工作需要为整体的目标服务，” doing them right”。除此之外，” doing things right”是验证things是否right的最有效的手段。但是，即使是最高效的工作方式，一旦离开了目标就毫无意义可言。
I have realised I did mistake his thought when I watched the next episode Agile Software Development: Without Code There Is No Business. So the opinions we express are actually the same.
I believe understanding the definition of a project and how to identify it is vitally important before learning project management. The purpose of distinguishing projects and BAU properly is to better manage and control the work in different contexts. More precisely, it could provide a basis for selecting concepts and techniques of management accordingly, and ensure applying them appropriately during executions. For instance, there are limited application contexts for different management methods and frameworks. As mentioned in chapter 1 of PRINCE2 Agile guide: “PRINCE2 and PRINCE2 Agile are only suitable for use on projects, whereas agile can be used for projects and routine ongoing work as well”.
PRINCE2 (PRojects IN Controlled Environments): a structured project management method and practitioner certification programme.
PRINCE2 Agile: the world’s most complete agile project management solution, combining the flexibility and responsibility of agile with the governance of PRINCE2.
There are no unique definitions of these two practices respectively I could found. In my view, it may be due to the specific environments in the distinct industries which the professionals considered when defined them. However, the interpretations of each of them are comparable in a manner.
“BAU work would typically be repeatable routine tasks that can be carried out by people with the appropriate technical skills without needing to be managed by a project manager“.
“the normal execution of standard functional operations within an organization – forms a possible contrast to projects or programmes which might introduce change“.
The two definitions indicate BAU is a ‘normal’ ‘routine’ work happening almost every business day. Like the common understanding of daily business work, it is executed basically in a fixed process environment which has the major characteristics of repetition, continuity and low risk.
“A project is a temporary situation where a team is assembled to address a specific problem, opportunity or change that is sufficiently difficult that it cannot be handled as BAU. It may even be a collection of BAU items handled collectively“.
“It’s a temporary endeavor undertaken to create a unique product, service or result“.
Compared with BAU, both definitions of projects emphasis ‘temporary’, which means the work of a project is not kind of permanent as BAU. In other words, a project should have its own corresponding and unique lifespan. Moreover, the aim of a project is to generate a ‘thing’ which does not exist in this world before including a concrete manner like a building, or a detailed solution for solving a prescribed requirement. Therefore, the processes of creating unknowns are more comparatively risk and each of them cannot be completely repeated.
PRINCE2 Agile guide
- Team is created
- A degree of uncertainty
- Stable team
- A degree of certainty
Strategic Project Organising
- One-off processes / unique
- Determinate lifecycle
- Temporary organisation
- Dynamic staffing
- Dynamic supply chain
- Owner/client engages in the process
- Commercial management
- Enables change
- Repetitive processes
- Indeterminate lifecycle
- Stable organisation
- Stable staffing
- Stable supply chain
- Process buffered from customer
- Supply chain management
- Keeps the business running
- One off/Unique
- Delivering ‘things’
- Project manager reporting
- Start/end time
- Bring about change
- More risky
- Line manager reporting
- Benefits from change
- Less risky
The content above lists the differences between projects and BAU from three different and representative sources orderly. According to these, projects and BAU are summarised and re-compared from six new themes, as shown in the following table.
The themes consist of:
- Organisation. The term ‘organisation’ indicates the execution team, external supply chain and other stakeholders. BAU has a stable supply and demand relationship and its producing process and structure should be fixed enough to achieve routine operation. Regards to projects, as an event responding to satisfy specific needs, the entire organizational structure and interest relationship would be established after the requirements generating. Moreover, this organisation will be disbanded after the value are achieved;
- Cost. Projects may generally be capitalized, while typically BAU may not be, due to the fact that the ongoing BAU work is depended on operating expenditures. It means that there are various accounting procedures for projects and other activities.
- Time. BAU work has an ongoing lifecycle without a predetermined end date. By contrast, A project is an event that achieves a prescribed purpose within a limited period of time. Hence, determinate time is a crucial characteristic of projects.
- Change. Projects and BAU respond differently to change. BAU teams operate existing business processes on a day-to-day basis. And the teams could realise changes and the impact on work as soon as they are implemented. As for a project, as mentioned above, is an event aiming at innovation. Project teams are working to incorporate all of the changes required.
- Risk. BAU teams attempt to identify and reduce all the operational risks. They seek to remove uncertainties for more stable and repeatable operation processes. Projects own a risk factor because of their nature of uniqueness and uncertainty. The business is only taking a leap into the unknown by undertaking a project because it implements change and creates something that wasn’t there before. Therefore, in order to reach goals and achieve the best outcomes, the project team sought to reduce the impact of risks by managing them.
- Output. This point is not mentioned in the comparison above. However, I believe that output is another major aspect of evaluating an event. It is determined by the goal of the event and the process performed. Projects are one-off event, not repeatable implementing to produce a new ‘thing’ or solution for solving a specific problem, opportunity or change. The output of a project is much more creative than BAU work obviously.
When I took the first lecture of the course ‘Strategy project Organising’, I was very impressive about that the lecturer asked us introducing some examples of projects and BAU work respectively. I remember a classmate who said at the time that producing a car was a project. But I pointed out that this is not while developing cars is. Now let’s re-evaluate the correctness of my answer based on the six themes summarised above.
For automobile production, it is certain that this is a day-to-day ongoing event in an automobile factory. The supply chain, assembly procedures, and acceptance criteria for each car have been clarified before production commences. This means that the budgets, resources, and output are controlled and stable and its process is repetitive. But for the research and development of new energy vehicles, for example, the reason for the start of this event is to meet the two requirements including people’s living and energy conservation and environmental protection. This is to solve a problem that has just emerged in modern society. Obviously, the traditional automobile manufacturing teams do not have the capability of researching and developing new energy engines and other technologies. Therefore, it is necessary to recruit experts from related fields to form a new research and development team. On the other hand, in order to maximise the benefits of automobile manufacturers, the research and development team needs to use controllable resources to produce feasible and unique solutions within a limited time.
The reason my classmate thought it was a project to produce a car maybe because he draws an analogy between it and building a house. What makes it different is that building a house is not a job that can be done on a unified assembly line with completely identical materials. Due to geographical conditions, construction conditions and other objective factors, the building process is non-repeatable, and the final output is unique.