sønder

“Tidsplanlægning kan ikke opfattes som en isoleret proces. Den hænger intimt sammen med organisations- og metodeplanlægning, ressource- og økonomiplanlægning samt andre af projektplanlægningens dicipliner.”

Citat er naturligvis Stenn Lichtenberg i “Projektplanlægning og styring”.

Og intimt! Her gik du og troede jeg slet ikke var ung og dynamisk. Ha! Det viser sig, præcis som jeg altid har sagt, at jeg ikke er bange for en udfordring. Er med på den værste. Projektplanlægning er nærværende og ikke til at leve uden.

Senere samme dag: Systematik og intuition. Sammenhængende?

Løse strøtanker om design af brugerstrukture af mindmaps på The Mindjet Weblog, følgende strøtanker om den successive metode.

1 Hand Rule
God put 5 digits on each hand to make counting to 5 easy for our arithmetically destitute ancestors and we got used to it. In the same vein, I recommend having no more than 5 topics at any one level. After 5 topics, the overall subject of the topics becomes muddled. Use the hierarchy.

Struktur ja. Undergruppering for at give gennemsigtighed. Klarhed for bruger. Hvordan bruger vi dette på vores weblogs, sovset ind i links til højre, adsence reklamer og tagclouds. Produktivitet/usab. Hvorfor skal vi opfinde den dybe tallerken, fremfor at bygge videre på gode teorier? Er det en god måde at sælge “weblogs bla bla bla” på?

Anden tanke går på dette citat:

MECE
MECE standards for “Mutually Exclusive, Collectively Exhaustive” and was developed by McKinsey as a framework for solving problems. I also think that it can be applied to mapping. The idea is that the topics should not overlap each other in their subject matter and all of the topics together should cover the topic completely. Easy for me to say, I know.

Jeg tænker her på Pareto princippet’s regler for ID af ressourcekrævende opgaver. Dernæst på successiv kalkulation, beskrevet af Steen Lichtenberg, brugt i tidsplanlægning. Mener her princippet om at ingen opgaver i den successive kalkulation må være direkte afhængige. Kendte usikkerheder som financiering, vintervejr, leverance, find selv på eksempler fra egen branche, grupperes for sig. De usikkerheder minimeres naturligvis efterhånden som de klarlægges. Så kan de beregnelige faktorer netop beregnes uden usikkerhed. Vi kan hurtigt bestemme prisen på gipsplader og kodearbejde udført i Bangalore eller varighed af inhouse udførsel af job for kunder. For at gøre det lidt mere vandt i blogtankegang, kan man pege til “The long tail“.

Startede på min bachelor igår. 2 dele. Et afgangsprojekt med titlen “Erhvervsbyggeri i Lisbjerg Erhvervspark”. Der kommer lidt grafik op senere. Bare rolig. For du vil jo gerne se hvad jeg laver, selvom du ikke vil være ved det. Dernæst et speciale centreret omkring “Byggeriets planlægning og styring”. Jeg vil muligvis, udover de umiddelbare tidsstyringværktøjsteorier også kigge lidt på informationsarkitektur som styringsredskab. Vi taler velgennemtænkt brugerorienteret design etc. Ja hvis jeg får tid, det gør jeg nok ikke. Mere om det senere.

Forhåbentlig dimension 30 juni. Også mere om det senere.

Lytter: Bloc Party “Banquet – Phone Disco Edit”, Frivolous vs DJG “Kisses – v3 edit” og Foster Sylvers “Misdemeanor”.

To much talk of software, and to little willingness to understand a there is a basic need for education in the theory of management. Examples of this is 43 Folders, the Signal/Noise people + the number of blogs praising/hyping these applications. As software toys they might do the job. But as tools helping a better understanding of the project, and hereby actually helping in efficiency and even more important, giving a higher project quality in the clients hand, I’m not that sure.

It’s fun playing with new toys, trying to understand them, making them do what you want them to do. But the applications, are created as efficiency helpers, not tools that will give the client a better project. So by not being fully aware of the tools that make a good product, you might just be wasting your own time and give the client a product he can’t use. Yes, everybody can see the path to completion. But what if the path and the goal is wrong and you thereby won’t be able to create a good and successful project.

An example of this is, that it starts further out than the brainstorm, it starts at approaching the brainstorm the right way. Understanding how it can bring clarity over the task and transferring this task into a problem solution, that will be effective and satisfy as many key stakeholders as possible. Can this clarity over the projects key indicators of success be shown and understood by all involved, then you can achieve the goal, other vise your failure rate will rise. Take a deep breath, close your software and start by learning the right way to achieve your goals. By choosing the right tool, not the newest software, the right strategic path to delivering the right product will be much more efficient and likely to be a success.