Comments on: Guidelines for eGovernment Projects http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/ Johannes Brodwall's Musings on Software Architecture and Programming Fri, 13 Apr 2012 19:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Houston Web Design / Designer http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-126642 Houston Web Design / Designer Sun, 28 Jun 2009 04:53:50 +0000 http://brodwall.com/johannes/blog/?p=363#comment-126642 Great article and I agree with you that ............ Thanks for the tips! Great article and I agree with you that ………… Thanks for the tips!

]]> By: Investment Opportunities http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-126641 Investment Opportunities Thu, 25 Jun 2009 05:21:30 +0000 http://brodwall.com/johannes/blog/?p=363#comment-126641 Hi...Your post really got me thinking man..... an intelligent piece ,I must say. Hi…Your post really got me thinking man….. an intelligent piece ,I must say.

]]> By: YL http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-124304 YL Fri, 05 Jun 2009 06:54:42 +0000 http://brodwall.com/johannes/blog/?p=363#comment-124304 Guess that it also might be a major issue that SSØ has a mixed owner structure (partly owned by the state and partly private). This causes different issues, especially, when SSØ has several positions around the table… from business point of view this position is not easy to handle.... <br><br>I would compare SSØ with Statsbygg - and by this draw comparison …. Guess that it also might be a major issue that SSØ has a mixed owner structure (partly owned by the state and partly private). This causes different issues, especially, when SSØ has several positions around the table… from business point of view this position is not easy to handle….

I would compare SSØ with Statsbygg – and by this draw comparison ….

]]> By: jhannes http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-124194 jhannes Thu, 04 Jun 2009 18:27:22 +0000 http://brodwall.com/johannes/blog/?p=363#comment-124194 Hi, Glen<br><br>Thank you for your follow-up. These are very important issues with a checklist and I agree with your evaluations of all of them. Hi, Glen

Thank you for your follow-up. These are very important issues with a checklist and I agree with your evaluations of all of them.

]]> By: Glen Farley http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-124193 Glen Farley Thu, 04 Jun 2009 17:56:54 +0000 http://brodwall.com/johannes/blog/?p=363#comment-124193 Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:<br>1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)<br>2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.<br>3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used. <br>4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes. Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:
1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

]]> By: Glen Farley http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-124192 Glen Farley Thu, 04 Jun 2009 17:55:54 +0000 http://brodwall.com/johannes/blog/?p=363#comment-124192 Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:<br>1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)<br>2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.<br>3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used. <br>4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes. Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:
1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

]]> By: Glen Farley http://johannesbrodwall.com/2009/06/04/guidelines-for-egovernment-projects/comment-page-1/#comment-124191 Glen Farley Thu, 04 Jun 2009 17:46:17 +0000 http://brodwall.com/johannes/blog/?p=363#comment-124191 Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:<br>1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)<br>2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.<br>3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used. <br>4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes. Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:
1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

]]>