Few things stall a website project like a quiet argument about who gets to say yes. The marketing lead wants a different theme, the developer wants to change the CMS version, the owner wants it live by month-end, and the editor just wants the publishing screen to stop breaking. This how-to walks through setting decision rights for a CMS change in seven concrete steps, so your next platform decision ends with a name, a date and a rule instead of another week of messages.<\/p>\n
Start by writing the change as a choice. “Fix the website” is a mood. “Move the blog from the current theme to a block-based one before the spring campaign” is a decision. If you cannot write the sentence, the group is not ready to argue about it, and arguing will only produce heat.<\/p>\n
Include the options. Typical CMS choices look like this: upgrade in place, rebuild on a new theme, migrate to a different platform, or leave things as they are and revisit later. Name them all so nobody smuggles in a fifth option halfway through the meeting.<\/p>\n
Draw a two-column table. The left side lists everyone touched by the change: editors, developers, designers, the person who runs newsletters, the person who pays the hosting bill. The right side holds the one name with authority to choose. Everyone in column one gets a voice; only one person in column two gets the pen.<\/p>\n
The decision-owner can be the product owner, the site manager or the business owner of a small company. The test is simple: when views conflict, who can say “we go with option two” and be obeyed without a second meeting?<\/p>\n
Do not assume. Ask the person directly, in writing: “Are you comfortable being the final decision-maker on this theme migration?” Also name a deputy who can decide if the owner is travelling or ill, because a decision that waits for one person’s return is a decision with a built-in delay.<\/p>\n
A deadline pulled from the air gets ignored. Link it to a real constraint: the end of a hosting contract, the date a campaign page must go live, a developer’s availability window. Then work backwards. The migration needs four weeks, so the decision must land by the first of the month at the latest, and the discussion window is therefore two weeks.<\/p>\n
If you are still gathering the basics of what the site must contain, the walkthrough titled planning your company site ahead of development<\/a> is a handy companion, since a good plan makes the owner’s choice far easier.<\/p>\n You have three options, and a short note on when each fits:<\/p>\n For most CMS platform decisions, the third rule is the practical default. It keeps the benefits of consultation without turning every opinion into a veto. Whatever you pick, write the rule where everyone can see it, ideally at the top of the project page or ticket.<\/p>\n Request a short note from each stakeholder, with three headings: recommendation, biggest concern, and what evidence would change my mind. Keep it to a single screen. Developers might mention compatibility with extensions; editors might flag training time; marketing might raise redirect planning. When you structure the input like this, the owner reads for patterns rather than sifting through long threads.<\/p>\n If the discussion touches the structure of the site itself, for example whether to add or retire pages, this structural guide to must-have business website pages<\/a> gives the group a shared reference point so you are all debating the same thing.<\/p>\n Many of us apply this pattern at home as well. A family arranging the practical, non-clinical side of someone’s trip abroad for care, covering dates, documents and who handles the budget, faces the same fog when nobody coordinates. People in that position sometimes read general background on BestHeartSurgery<\/a>, which presents itself as an information resource for patients and relatives and says it does not offer treatment. The same trio of owner, date and rule keeps the paperwork moving.<\/p>\n When the owner decides, write down four lines and share them:<\/p>\n The record prevents the reopening of settled questions and gives future team members the story. The review date lowers the stakes, because people accept a decision more easily when they know it can be adjusted with evidence. Teams who skip this step tend to find the same argument returning every quarter.<\/p>\n Decision rights are not a separate activity from design, content and testing; they sit at the top of all of them. A homepage redesign, for instance, involves dozens of small choices, from hero wording to navigation labels. Naming an owner for each cluster of choices speeds the work and protects the quality. Readers working on the visitor-facing side may like this look at how homepage design influences what customers think<\/a>, which shows how many judgement calls hide inside one page.<\/p>\n Copy these lines into your project tool and fill them in before the next meeting: the change in one sentence, the options, the owner and deputy, the deadline and its external anchor, the rule, the input format, the decision record and the review date. It takes a quarter of an hour. Compared with the weeks that unclear decision rights tend to consume, it is the cheapest piece of project management you will do this year.<\/p>\n","protected":false},"excerpt":{"rendered":" Platform changes stall when nobody owns the call. Seven practical steps to name an owner, set a deadline and pick a rule before the debate begins.<\/p>\n","protected":false},"author":14,"featured_media":6145,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1455],"tags":[],"class_list":["post-6144","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development"],"_links":{"self":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6144","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/comments?post=6144"}],"version-history":[{"count":1,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6144\/revisions"}],"predecessor-version":[{"id":6206,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6144\/revisions\/6206"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/media\/6145"}],"wp:attachment":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/media?parent=6144"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/categories?post=6144"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/tags?post=6144"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Step 5: Choose the rule and write it on the page<\/h2>\n
\n
Step 6: Collect input in a fixed format<\/h2>\n
A short aside on decisions outside the website<\/h2>\n
Step 7: Record the decision and set a review point<\/h2>\n
\n
Common failure points and quick fixes<\/h2>\n
\n
Where this fits in a wider project<\/h2>\n
Your one-page template<\/h2>\n