A biennial planning process makes a lot of sense, so long as transparency and accountability is not lost.
In the planning year, the most resource efficient way of doing this stuff is to make strategy and operations 6 months out of phase, ensuring that the management and executive don't exhaust themselves with an impossible burden. Going a step further and designing a biennial cycle, makes it possible to be more ambitious with a 24 month horizon rather than just the financial 12 months, so the organization can consider significant organizational changes to complete in that time, and be more transparent about being measured. For example, if something new is performing very badly in the first 3 months, the fact that you have up to 21 more months to turn it around, or completely reset, be creative, and still deliver against the measurable strategic targets, is much more realistic. So, good, I hope the WMF jumps over to this way of working, they should be mature enough by now. Fae On 15 March 2017 at 17:46, Pine W <[email protected]> wrote: > For what it's worth, my understanding is that WMF is considering > transitioning portions of its annual planning to biannual planning. > > Also, I think that it will be easier to develop a long term technical > roadmap after WMF completes its strategy update. > > Pine > > > On Wed, Mar 15, 2017 at 12:19 AM, Rogol Domedonfors <[email protected]> > wrote: > >> A good way of avoiding clashes would be to publish the technical roadmap >> showing where WMF expects to be taking its technical development over the >> next five years or so, for the community to discuss and comment on I have >> yet to hear any reason why this can not or should not be done. >> >> "Rogol" >> >> On Wed, Mar 15, 2017 at 1:48 AM, Pine W <[email protected]> wrote: >> >> > Quim, >> > >> > Thanks for the comments. >> > >> > A brief note about the goal of "there are no clashes between product >> > development teams and communities". That is an ambitious goal around >> here, >> > partly because there are changes planned and happening concurrently in so >> > many places that I think it would be a challenge to surface all potential >> > conflicts early and make them visible to relevant community members. (As >> an >> > example, a change that might be received favorably on Wiki A might >> generate >> > a commotion on Wiki B because it broke an existing tool, made an existing >> > workflow take longer, or conflicts with their community's priorities. A >> > current example of this kind of situation is with Flow, which the last I >> > heard is viewed favorably on Catalan Wikipedia and unfavorably on English >> > Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm >> > thinking that once the Newsletter extension is working, that might be a >> > useful way of informing more interested people in a more timely fashion >> > about planned changes, and encouraging people to enroll as beta testers >> and >> > translators, so that there are fewer surprises. >> > >> > I think that what might be a more readily solvable problem would be a >> > standardized way of resolving clashes between product teams and >> communities >> > so that, when such clashes almost inevitably happen at some point, >> > resolution comes sooner rather than later and hopefully in a way that is >> > mutually acceptable. Perhaps that could be discussed in the Technical >> > Collaboration Guidance document. >> > >> > Pine >> > _______________________________________________ >> > Wikitech-l mailing list >> > [email protected] >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- [email protected] https://commons.wikimedia.org/wiki/User:Fae Personal and confidential, please do not circulate or re-quote. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
