Lessons Learned: Don't Let BCP Become the Last Barrier to Project Closure

In many ERP implementation projects, Business Continuity Planning (BCP) is included as part of the Go-Live deliverables. While the implementation team often focuses on system deployment, UAT, and Hypercare, the BCP document may receive less attention until the final acceptance stage.

This can create an unexpected project risk.

What happened?

The ERP system was already in production and business operations were running successfully. However, the customer continued reviewing the BCP document and requested additional details, including manual workaround procedures, recovery sequence, department responsibilities, and testing expectations.

As the BCP document was part of the Go-Live acceptance package, the project could not be formally closed until the document was approved.

As a result:

• Go-Live acceptance was delayed.
• Project closure was postponed.
• Final milestone payment could not be invoiced or collected.
• Additional project effort was required during Hypercare to address review comments.

Root Cause

The scope and acceptance criteria for BCP were not fully aligned with the customer during the planning phase.

Different stakeholders had different expectations regarding:

• BCP documentation
• BCP testing
• Operational readiness
• Recovery procedures
• Business ownership

These expectations only became visible during the final review process.

Best Practices

Before Go-Live, every ERP project should clearly agree on:

• Is BCP part of the contractual deliverables?
• Is only the BCP document required, or is BCP testing also required?
• Which business processes and departments are included?
• Who is the final approver?
• What are the acceptance criteria for BCP approval?

These items should be documented in the Statement of Work (SOW), Go-Live checklist, or Acceptance Criteria.

Key Takeaway

A delayed BCP approval is not only a documentation issue—it can become a commercial risk. When BCP is included in the Go-Live acceptance package, unresolved BCP reviews may delay project acceptance, postpone project closure, and impact milestone payments.

Early alignment on BCP scope and acceptance criteria helps reduce review cycles, prevent scope creep, and protect both delivery and commercial objectives.

Jar of Love:: Cất một tình yêu vào trong chiếc bình

 

Jar of Love – Cất một tình yêu vào trong chiếc bình: https://www.youtube.com/watch?v=t4Os4nxEBfI&list=RDt4Os4nxEBfI&start_radio=1 

Có lần Trò Bùi tình cờ nghe lại bài Jar of Love của Wanting Qu qua một đoạn Reels ngắn. Bài hát này ra đời đã hơn 10 năm nhưng lạ thay, mãi đến bây giờ Trò Bùi mới thật sự ngồi nghe kỹ.

Nhiều bài hát nổi tiếng nhờ giai điệu bắt tai. Còn Jar of Love lại giống một cuộc trò chuyện với chính mình hơn. Trò Bùi không cảm nhận đây là bài hát nói về một tình yêu mãnh liệt. Ngược lại, nó nói về sự lưỡng lự, thiếu chắc chắn và những câu hỏi mà có lẽ ai cũng từng tự hỏi mình:

"Mình có xứng đáng không?"

"Liệu người đó có ở lại không?"

"Nếu mở lòng thêm một lần nữa thì sẽ ra sao?"

Người nhạc sĩ dường như không vội vàng lao vào tình yêu. Cô ấy đứng lại, suy nghĩ rất lâu. Có cảm giác như đang cân nhắc giữa việc bước tới hay quay lưng đi. Rồi sau tất cả những lần tự vấn ấy, cô quyết định tiến tới. Điều làm Trò Bùi thích nhất chính là hình ảnh jar of love. Đó là một hình ảnh dễ hình dung ra nhạc sĩ muốn ám chỉ điều gì!!

Tình yêu vốn là thứ vô hình, không nắm được, không giữ được. Nhưng trong bài hát này, tình yêu được đặt vào trong một chiếc bình như một vật quý giá. Có thể không phải vì muốn chiếm hữu, mà bởi vì sợ nó biến mất. Khi tìm được một điều thật sự quan trọng, người ta thường có xu hướng muốn giữ nó lại cho riêng mình. Muốn cất nó ở một nơi an toàn để gió không cuốn đi mất.

Về phần âm nhạc, Trò Bùi  vẫn thích bản acoustic hơn. Sau này bài hát được phối lại theo hướng pop với nhiều nhạc cụ điện tử hơn. Bản mới nghe hiện đại, mượt mà và dễ tiếp cận hơn. Nhưng với Trò Bùi, nó lại mất đi một phần cảm xúc. Bản acoustic có những khoảng lặng, những hơi thở và cả những chỗ chưa hoàn hảo. Chính những điều đó làm cho người nghe cảm thấy như có một người thật đang ngồi trước mặt kể chuyện.

Bài viết liên quan, cùng 1 cảm xúc: https://www.gautocxia.com/2024/06/rang-o.html

Chuyến đi Hampi năm 2011 cùng lứa đầu vô Bosch

Nhân dịp Ấn Độ ra đồng tiền mới Rs 50, mình lục lại kỉ niệm chuyến đi Hampi năm 2011 cùng lứa đầu vô Bosch.

Bỏ qua mấy vụ lặt vặt đi quanh Bangalore, Tumkur (tôm cua) rồi Mysore, mình vẫn cảm thấy chưa đủ phê. Cần làm một chuyến đi xa và nhớ đời trước khi về nước. Lục loại quanh bản đồ du lịch Ấn Độ, thì mình lựa 1 nơi cổ cổ, di chuyển được và là di sản văn hóa thế giới. Cái tên Hampi lù lù ra. Phải nói rằng mình chọn Hampi vì nó là một dạng "group of monuments at Hampi", đi được nhiều cái hay một lúc, cũng như Cố Đô Huế nhà mình.

Cái thời Google maps chưa có, ít người dùng smart phone, thông tin du lịch hạn chế, để làm một chuyến xa lên miền bắc Karnataka có thể nói là hơi liều và mù thông tin. Kệ, làm cú chót. Không biết ru rê răng mà cuối cũng được 9 đứa đi. Mình mang tiếng chủ xị nhưng lên lịch chính, thiết kế chương trình là ku Lê Ngọc Minh, còn cơm nước là chị em phụ nữ Phuong-Dung Bui.

Cả đám đi xe buýt lên Majestic, rồi mò vô bến xe. Khổ ghê. Để hỏi đường vô bến xe mua vé mà cũng khổ. Mạ, hỏi lối vào bến xe không mà cũng khó. "Where is the entrance?", mình phát âm là "en trần", bác không hiểu rồi chuyển sang "in trên" mới hiểu. Hài. Kệ dù sao gà lần đầu thì lần sau rút kinh nghiệm.

Cả đám chờ xe đến 9h thì mò lên, bắt ghế nằm phò, chờ di chuyển đến Hospet. Xe khá là sang và lịch sự. Dân Ấn có vẻ không quan tâm cái đám leo nheo, ồn ào lên xe. Chắc họ cũng nghĩ tụi ni là dân Nepal hay Manipur ngèo đói chi đó. Y như rằng dân Việt Nam qua là nghèo, tau không thèm chơi thèm quan tâm, họ ngủ rồi chờ đợi sáng mai tới nơi. Mình cũng ngủ, chả biết trời trăng chi. Đến khuya thì mở mắt ra, xe chầm chậm băng qua cái đèo nhỏ, một bên là vách đá, kiểu như đèo Hải Vân. Không rõ người ta đang đục đục kiếm đá hay tự nhiên đá lởm chởm như rứa. Trời tối và mờ ảo, không nhìn rõ được chi. Cố gắng ngủ tiếp, vì xe sẽ tới vào sáng sớm mai.

Xe cũng tới bến Hospet, xuống xe thôi. Hospet là nơi trung chuyển. Dù hơi mệt, phải banh mắt ra sáng sớm 5h sáng nhưng cũng hào hứng vì mình đang tới tới 1 nơi khá xa lạ. Quang cảnh khá đìu hiu, chắc là vẫn một dạng làng quê, chưa phát triển lắm. Để di chuyển 10KM tới Hampi thì phải đi bằng xe Rickshaw. Đường vô Hampi như đường vô Nandhi Hills, toàn đất đá lởm chởm. Người ta chỉ trồng được bắp và các loại hoa quả đơn giản, ngắn ngày. Đi ngang mà vẫn thấy 1 bác Ấn đang thả bom sát đường lộ, haha. Thôi kệ, một dạng bón phân u rê mà.

Mình ló đầu nghía qua chiếc Rickshaw, một cái cổng đền đồ sộ hiện ra là biết ngay đã tới Hampi. Như thường lệ của người sống đơn giản, ưa tự do thì hành trang chỉ có cái balo đựng laptop, quần Jean, áo sơ mi và đôi dép Lào nát bét mòn đế. Không hề chi, nghèo thì sống đơn giản cho nó khỏe. Cái tật là vô đền ở Ấn là phải di chân trần, nên mình gửi dép. Hê hê. Mà gửi rứa thôi chứ không có lấy số dép Tranh thủ làm vài pô trước khi chính thức đặt chân vào đền Virupaksha. Phải nói là cái đền ni nó hoành tráng, dài, đồ sộ mà chưa bao giờ, kể cả mình lê lết ở Án gần 2 năm mà thấy được. Đúng là di sản văn hóa thế giới có khác, cái đền chính ni nó hoành tráng. Bên trái gồm các tảng đá lớn, xui, nơi đây bạn có thể ngắm hoàng hôn xuống khi trời chạng vạng tối. Bên phải có một cái bể chứa nước nhỏ. Vùng đất khô hạn mà, phải có cái chi đó để chứa nước. Rất lạ là cái chánh điện (đền) ở giữa không có nhà tu nào, chỉ toàn tượng đá. Nhà tu nằm bên phải cái chánh điện, nhỏ và khá tối vì nó làm kiểu hang đá, kiểu như một dạng hang động bằng cách đục đá. Mùi thì rất riêng biệt của đạo Hindu. Không biết mùi chi mà nến cháy suốt ngày đêm và hoa được phủ lên các bức tượng của vị thần tạo ra một mùi rất riêng. Không biết dưới cái đền ni có cất vàng bạc của dân tình cúng viếng không chứ Ấn Độ nổi tiếng có các đền chứa đầy vàng bạc lên đến cả tỷ USD. Lúc mô cũng rứa, đền thờ Ấn Độ, nhất là miền Nam được chạm khắc cầu kì, rất phức tạp nhưng bố cục rõ ràng, không gây cảm giác chằng chịt hoa văn và rối mắt. Lợi thế ở đền làm bằng đá, thời tiết khô cằn, dân thì sùng bái thần linh thì nó sẽ ít bị bào mòn bởi thời tiết, tác động của con người. Bởi rứa đền ở Ấn Độ lên tới 1000 năm là bình thường.

Chơi miết cũng đói bụng. Cảm đám 9 đứa kiếm chỗ ăn trưa. Vòng ra sau ngôi đền là đường đi lên các tảng đá, cũng có nhiều cái đền , cũng có một ngôi trường nhỏ. Phải đi chân trần qua đó, gai từ các bụi cỏ chích chích đau đau. Ngó mà vui, mấy đứa chia nhau thức ăn, tình cảm. Ở đây có cá mảng xanh mướt và hoa vàng xen kẻ nhau. Mình thì nằm phè ra, cảm giác rất tự do.

Ở Hampi ni, vì có rất nhiều đền cả đám cố gắng khám phá càng nhiều càng tốt. Mấy thằng mấy con lết bộ mêt bỏ xừ. Trời thì khá nắng mà nước ở đây vô cùng hiếm, không thấy một tiệm bán nước mô. Kể cũng lạ, vua chúa chi mò vô đây xây dựng kinh đô mà nước uống hiếm quá, cho dù có một con sống chảy ngang qua. Cảm đám đi bộ một đoạn khá dài rồi cũng tới được một ngôi đền. Có đền thì mò vô tham quan thôi. Tên đền thì làm răng mà nhớ được vì nhiều đền quá, vả lại tiếng Kannada thì cũng bó tay. Tiếp tục cuộc hành trình. Vua thời xưa chắc thích chơi trội mà xây nguyên cái đền nằm dưới mặt đất, Underground Temple. Chắc ông nghĩa là đền nằm hẳn dưới đất mát hơn nằm trên đất. Cũng có lý của nó, cái đền ni nó ngập nước, ẩm mốc và có mùi khó chịu. 2 thằng chụp vài pô xong rồi chuồn. Trời vẫn còn đang nắng. Cả bọn nghỉ ngơi hồi lâu, tám đủ thứ trên trời dưới đất, lấy sức để đi tiếp.

Cả bọ dừng chân ở Elephant Temple. Mà vé vô tới 200 Rs dành cho dân nước ngoài. Tiếc tiền nên tính cách khác, bỏ qua cái đền ni. Tình hình là như ri, một là đi vòng, rất xa mà hàng quán nước không có, 2 là đi băng qua núi, gần hơn. Bản tính mà, nhác, cả bọn chọn đi băng qua núi. Nói rứa chứ thành hên dễ sợ. Sau khi băng 1 đoạn đồi nhỏ, thì cả đám tới một ruộng bỏ hoang. Muốn xuống thì phải nhảy qua tảng đá chứ không có đường. Đi là đi mù rứa thôi chứ không biết phía trước là gì. Cả bọn phải băng qua cái lạch nhỏ, rồi tới cái suối lớn. Con trai thì không vấn đề gì, chị em phụ nữ cần giúp đỡ. Không biết mô ra có bác nông dân người Ấn hướng dẫn cho cả đám qua suối. Nước chảy khá xiết. Mình không biết mô tả cụ thể ra răng, trên là cây ối um tùm che hẳn dòng suối đá bên dưới. Cả bọn phải băng qua thêm một đoạn đường mà hình như không biết dẫn tới mô, cứ đi là đi thôi. Sau khi băng qua vài ruộng nước thì tới một ngôi đền cổ. Ở đây khá đổ nát và không một bóng dân du lịch. Chắc là em nó nằm trong rừng sâu, đường xa tiếp cận khó khăn nên hoang vắng. Cái đền khá to, đổ nát, các cái cột chống hư hại nhiều. Vì đi tắt nên cả đám đi vào đền bằng đường sau. Phía trước cổng đền là một cái giếng khá to. Nước không còn nhiều. Cũng không biết xây cái giếng ni làm chi vì xa xa là sông Tungabhadra chảy ngang qua.

Cả bọn ghé qua dòng sông ăn xế. Mà nước ở đây đỏ kè, chắc là nhiều sắt Fe. Nước tuy cạn nhưng nguya hiểm á. Nước chảy khá xiết và trơn tuột. Mình và thằng Tien Cao đánh lẻ đi khám phá thêm đằng sau khu núi. Ở sau có các tảng đá được chạm khắc, và các bức tượng nằm xen kẻ dưới dòng sông. Xa xa có chú chèo thúng đánh cá. Ở đây không có thảo mộc chi nên không biết cá lấy chi mà ăn. Mình đoán cá không nhiều. 2 thằng thay nhay chụp ảnh rồi tụ tập với nhóm. Ăn uống ngay trên các tảng đá, chân thì vọc nước, cảm giác thật thích thú. Thì cả ngày đi bộ, chừ là lúc nghỉ ngơi coi như là mát xa chân.

Phải nói là Hampi có rất nhiều đền cổ, công trình cổ cho dù nát bét gần hết. Nếu có sức và bạn yêu thích những gì cổ xư thì cần 2 ngày thì đi hết Hampi. Xa tít trên rặng núi đá tuốt trên cao có một có đền. Mình thích lên đó nhưng đã 6h tối rồi nên đành chịu. Màn đêm cũng buông xuống, cả bọn đi kiếm ăn. Ở đây du lịch, thời điểm 2011, chưa phát triển lắm, nên chỉ có vài hàng quán lèo tèo. Thì chịu khó ăn được cơm chiên, dằn bụng để ra Hospet 9h tối đón xe về Bangalore. Cơm nước xong xui, mình đùa giỡn với 1 ku Ấn. Ku Lê Ngọc Minh khóc lóc, nói em quên cái kiếng ở sông, nơi mà cả đám ngồi ăn xế ở chiều. Chừ răng, cái đó là đồ kỉ niệm, bạn em mua ở chợ Đông Ba. Thì thôi, 2 anh em mò xuống. Mẹ nó, đi ngang qua thì bị 2 thèng chặn lại, rằng là rất nguy hiểm, nó đòi dẫn đường. Nó đòi dẫn đường. Mình thì không sợ chi, có quái mô ở dưới đó mà ma với cướp. Nói rứa thôi, trời thì tối, đường làng mà làm chi có đèn, toàn đền cổ nên trông như xử sở ma quỷ. Có dân bản địa cũng hơn. Mình dặn lòng là có gì hăn chấn lột hay cướp bóc thì tau đập chít thằng dẫn đường nghe Minh. Vừa đi vừa nhìn đường vừa nhìn coi có cục đá mô không. Lỡ có chi thì lượm đá choảng liền. Một bên là tảng đá, một bên là sông. Đi khoảng 10 phút, 3 thèng từ ngôi đền hoang vắng, tối mù, cộng thêm cây đa lắc nhẹ gió, 2 thằng mò bậc thang xuống dòng sông. Thì cũng may, hắn cũng tìm ra cái kiếng. Thì nó vẫn nằm đó chứ mô, xứ xở ni ai mò xuống làm chi mà mất mát. Mà công nhận không biết liều hay ngu, cái kiếng vài ba đồng bạc mà liều mình bò xuống cái nơi hoang vu, kinh dị như ri. Mình bảo đảm thèng mô nhát chít thì đi ba bước đã tè ra quần. Như ma ám í.

2 thằng trở lại với nhóm rồi ra bến xe. Shopping linh tinh rồi về Bangalore. Hampi rất hợp cho những bạn yêu thích đền đài, cổ kính, yêu thích lịch sử. Cho dù mình đi khá nhiều nơi Ấn Độ nhưng nơi đầu tiên mình cảm thấy được khám phá, được tung hoành với lứa bạn đầu tiên ở Bosch thì rất vui. Cho dù sao đi nữa, lâu quá không gặp, nhưng những kỉ niệm với Tien Cao, Lê Ngọc Minh, Phuong-Dung Bui, Chi Pham không bao giờ quên.

Scope Creep and Gold Plating:: The Old Problems Every Software Project Eventually Meets

Một Cái Nút Nhỏ, Một Bài Học Lớn Hơn

Sáng nay tôi có một cuộc trao đổi khá thú vị với một bạn developer trong team.

Bạn ấy đã implement một thay đổi cho đoạn text của một button đã được sử dụng trong hệ thống suốt nhiều năm qua. Khi tôi hỏi lý do, bạn giải thích rằng đoạn text mới chính xác hơn về mặt ngữ nghĩa và phản ánh đúng hành động của người dùng hơn. Về mặt kỹ thuật, bạn ấy không sai. Thậm chí có thể nói là đúng.

Nhưng với vai trò Product Owner, câu hỏi tiếp theo của tôi rất đơn giản:

Lợi ích cho khách hàng là gì? 

• Cả hai cùng im lặng một lúc.

Rồi tôi tiếp tục hỏi.

Người dùng hiện tại có đang hiểu sai ý nghĩa của button này không?

• Không.

Có ticket, complaint hay feedback nào liên quan đến button này không?

• Không.

Có trường hợp nào người dùng bấm nhầm nút vì đoạn text hiện tại không?

• Không.

Nó có gây ra vấn đề nghiệp vụ nào không?

• Không.

Việc đổi text có giúp giảm effort đào tạo người dùng không?

• Không.

Việc đổi text có giúp tăng năng suất làm việc không?

• Không.

Có yêu cầu nào từ khách hàng hoặc business owner không?

• Cũng không.

Đến lúc đó, cả hai đều hiểu cuộc trao đổi đang đi về đâu. Đề xuất này vẫn cần effort để phát triển. Vẫn cần effort để kiểm thử. Vẫn cần cập nhật tài liệu. Vẫn cần cập nhật release note.

Và với vai trò Product Owner, cuối cùng tôi vẫn phải giải thích được giá trị kinh doanh của thay đổi này. Tất cả những việc đó chỉ để thay đổi một button vốn đã hoạt động ổn định suốt nhiều năm. Đúng là đoạn text mới có thể chính xác hơn. Nhưng chính xác hơn chưa chắc đã tạo ra giá trị.

Trong phát triển phần mềm, chúng ta rất dễ rơi vào cái bẫy cho rằng bất kỳ sự cải tiến nào cũng là một cải tiến có giá trị, chỉ vì nó làm sản phẩm trông gọn gàng hơn, đẹp hơn hoặc "đúng" hơn. Nhưng sản phẩm không tồn tại để thỏa mãn cảm giác hoàn hảo của đội phát triển. Sản phẩm tồn tại để giải quyết vấn đề cho khách hàng. Sau khi trao đổi, tôi quyết định từ chối đề xuất này. Không phải vì bạn developer sai. Thực ra ý định của bạn ấy hoàn toàn tốt. Bạn muốn cải thiện sản phẩm. Nhưng quyết định về sản phẩm cần được dẫn dắt bởi giá trị, không phải bởi sở thích cá nhân. 

Cuộc trao đổi nhỏ đó làm tôi nhớ lại một điều mà tôi đã học được nhiều lần trong suốt sự nghiệp của mình:

Không phải mọi cải tiến đều thực sự là cải tiến. 

Đôi khi quyết định tốt nhất là không thay đổi gì cả.

Đặc biệt khi không có vấn đề nào thực sự cần được giải quyết.

Là Product Owner hay Project Manager, trách nhiệm của chúng ta không chỉ là hỏi:

"Chúng ta có làm được không?"

Mà quan trọng hơn là phải hỏi:

"Tại sao chúng ta phải làm việc này?"

Câu kết "Tại sao chúng ta phải làm việc này?" thực ra chính là cốt lõi của Product Management. Developer thường tập trung vào giải pháp. PO phải tập trung vào giá trị. Và rất nhiều Gold Plating bắt đầu từ việc cả team nhảy ngay vào giải pháp trước khi xác định xem có vấn đề nào thực sự tồn tại hay không.

The flowers are in full bloom

 The leaves have all fallen, 

     -- the flowers are in full bloom, 

          -- creating a truly spectacular sight.

Source: https://indianexpress.com/article/lifestyle/life-style/bengaluru-under-golden-shower-as-tabebuias-or-golden-trumpet-trees-turn-yellow-8490671/

 

The Value Chain in Software – Through the Lens of PM and Product

1. PM at the Lowest Level: Task Coordinator

In low-value outsourcing models, the Project Manager mainly:

• Tracks timeline

• Reports status

• Manages scope changes

• Follows client instructions

The PM does not influence the product direction.
The client decides everything.

Here, the PM is managing execution, not value.

This is similar to managing a factory line.

2. PM as Delivery Owner (QCD Focus)

Next level:

• Challenges unclear requirements

• Manages risk proactively

• Suggests technical improvements

• Balances scope, cost, and timeline

Now the PM protects quality and delivery, not just schedule.

Still execution-focused, but with ownership.

This is already higher in the value chain.

3. PM as Solution Partner

Now it shifts.

The PM:

• Understands business goals

• Connects technical work to business impact

• Proposes better approaches

• Advises the client

Instead of asking:
“What should we build?”

The PM asks:
“What problem are we solving?”

At this stage, the PM influences value, not just output.

4. Product Management – Moving to the High-Value End

Product management sits further to the right of the value chain.

A strong Product Owner:

• Defines roadmap

• Prioritizes based on market value

• Understands user behavior

• Makes trade-offs

Product management is not about managing tasks.
It is about deciding what not to build.

That decision alone creates huge value.

5. Managed Service – The Bridge Up the Chain

This is important.

When you move from:

“Project-based delivery”
to
“Managed service with SLA/KPI”

You are moving up the value chain.

Why?

Because now you:

• Own performance outcomes

• Define service scope

• Control operational standards

• Build long-term client dependency

You stop selling effort.
You start selling reliability and results.

The Strategic Difference

Low-value zone:

• PM manages activities

• Product follows instructions

• Revenue depends on manpower

High-value zone:

• PM manages outcomes

• Product defines direction

• Revenue depends on value delivered

What This Means in Reality

If a PM only:

• Tracks tickets

• Sends reports

• Escalates issues

That PM stays in the middle of the curve.

If a PM:

• Understands domain deeply

• Advises on solution design

• Drives risk strategy

• Shapes service model

That PM moves toward the high-value end.

Same title. Very different impact.

Simple Summary

Execution manages work.
Ownership manages value.
Strategy manages direction.

In software, moving up the value chain means shifting from managing tasks to owning outcomes.

That is where project management and product management become strategic, not administrative.

Reference:

• Drucker, P.F. (1993) Post-capitalist society. New York: Harper Business.

• Levitt, T. (1972) ‘Production-line approach to service’, Harvard Business Review, 50(5), pp. 41–52.

• OECD (2013) Interconnected economies: Benefiting from global value chains. Paris: OECD Publishing.

• Project Management Institute (PMI) (2021) A guide to the project management body of knowledge (PMBOK® Guide). 7th edn. Newtown Square, PA: PMI.

• Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. Available at: https://scrumguides.org (Accessed: 03.02.2026).

• Shih, S. (1996) Me-too is not my style: Challenge difficulties, break through bottlenecks, create values. Taipei: Acer Foundation. (Smile Curve concept).

• World Bank (2020) World development report 2020: Trading for development in the age of global value chains. Washington, DC: World Bank.

• Porter, M.E. (1985) Competitive advantage: Creating and sustaining superior performance. New York: Free Press.

• McKinsey Global Institute (2016) Digital globalization: The new era of global flows. New York: McKinsey & Company.

• ITIL (2019) ITIL Foundation: ITIL 4 edition. London: TSO (The Stationery Office).

• Gereffi, G., Humphrey, J. and Sturgeon, T. (2005) ‘The governance of global value chains’, Review of International Political Economy, 12(1), pp. 78–104.

Further read: https://www.gautocxia.com/2026/03/the-value-chain-in-software-development.html 

The Value Chain in Software Development

The Value Chain in Software Development

When people think about software, they often think about coding. But coding is only one small part of the full value chain.

The value chain in software means all the steps that create value — from the first idea to the final product running in the market. Not all steps create the same level of value. Some roles earn much more because they control the problem, not just the solution.

Let’s break it down.

1. Pure Coding (Execution Work)

This is when a client provides detailed requirements, and the team writes code based on instructions.

• No decision power

• No product influence

• Paid by hour or man-day

This is similar to assembly work in manufacturing. Important, but low margin. Easy to replace. Competes mostly on price.

Many outsourcing companies operate at this level.

2. Technical Design and Engineering Ownership

Here, the team does more than coding.

• Defines architecture

• Suggests better solutions

• Reviews requirements

• Makes technical decisions

Now the company is not just a pair of hands. It brings expertise. Margins improve. Clients rely more on the team.

This is already a move up in the value chain.

3. Product Engineering / Co-Creation

At this stage, the team participates early.

• Understands business needs

• Shapes features

• Improves user experience

• Thinks about scalability and long-term impact

The discussion shifts from “What should we build?” to “Why are we building this?”

Now value increases significantly. The company becomes a partner, not just a supplier.

4. Product Strategy and Solution Ownership

This is where real power sits.

• Defines roadmap

• Owns scope, cost, quality

• Balances technical and business decisions

• Drives outcomes, not tasks

Here, the company sells solutions, not resources.

It is no longer billing hours. It is delivering results.

5. Product Ownership (IP and Platform)

This is the highest level.

• Owns the intellectual property

• Builds a product or platform

• Generates recurring revenue (for example SaaS)

• Controls pricing and direction

Now value comes from scale, not effort. One good product can serve thousands of customers.

This is where margins are strongest.

The “Smile Curve” in Software

If you draw a curve:

• Left side: Idea, design, strategy → High value

• Middle: Coding and testing → Lower value

• Right side: Branding, product control, platform → High value

The middle is execution. The ends are ownership.

Why This Matters

For countries and companies, staying in low-level coding means:

• Competing on cost

• Limited profit

• High pressure

Moving up the value chain means:

• Stronger margins

• Strategic influence

• Long-term sustainability

It is not about writing more code.
It is about owning more decisions.

In simple terms:

If you only build what others design, you stay replaceable.
If you help define the product, you gain leverage.
If you own the product, you control the game.

That is the real value chain in software.

Reference:

• Drucker, P.F. (1993) Post-capitalist society. New York: Harper Business.

• Levitt, T. (1972) ‘Production-line approach to service’, Harvard Business Review, 50(5), pp. 41–52.

• OECD (2013) Interconnected economies: Benefiting from global value chains. Paris: OECD Publishing.

• Project Management Institute (PMI) (2021) A guide to the project management body of knowledge (PMBOK® Guide). 7th edn. Newtown Square, PA: PMI.

• Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. Available at: https://scrumguides.org (Accessed: 03.02.2026).

• Shih, S. (1996) Me-too is not my style: Challenge difficulties, break through bottlenecks, create values. Taipei: Acer Foundation. (Smile Curve concept).

• World Bank (2020) World development report 2020: Trading for development in the age of global value chains. Washington, DC: World Bank.

• Porter, M.E. (1985) Competitive advantage: Creating and sustaining superior performance. New York: Free Press.

• McKinsey Global Institute (2016) Digital globalization: The new era of global flows. New York: McKinsey & Company.

• ITIL (2019) ITIL Foundation: ITIL 4 edition. London: TSO (The Stationery Office).

• Gereffi, G., Humphrey, J. and Sturgeon, T. (2005) ‘The governance of global value chains’, Review of International Political Economy, 12(1), pp. 78–104.