jump to navigation

Evaluation of the process of change July 16, 2007

Posted by alwilliams in Production Analysis.
add a comment

From the discussions and establishment of a list of variables that affect the process of change (www.cemp.ac.uk/macmp/wiki/index.php?title=Change)
it became clear that there are many forces at work that influence both the effectiveness of the change(s) made and the ease in which change could occur. Here I have pulled out the most salient variables, which I believe have the greatest impact on what can be described as “change management”.

Time Restrictions:

Time is money and places a great deal of pressure on the work environment, which results in the need for prioritisation and shifting deadlines. Embarking on Action Inquiry (AI) is likely to take more time than if no data collection and data analysis stages were included in the process. These stages are crucial, but need to be accounted for in how long they are likely to take. Some students (e.g. http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335) found that they ran out of time because they were not aware of how long the change would take to make. In this particular case the project was an addition to the existing workload and the temporal demands placed on the project leader led to the project being left incomplete. Therefore when embarking on change, an analysis needs to be made to ensure there is enough room in the diary. This also ties in with priority however where a lower priority project should be fit into the diary, whereas for a more urgent project time might be shifted around to account for its priority level.

It is simply counter productive if there turns out to not be enough time to complete a project. Time would have been spent on working on an AI for the momentum to have been lost, while waiting for sufficient time is available to complete the project. Further more it takes time to pick a project back up again, which results in more lost time. It is important to get the timescale and timetable firmly defined in order to avoid this situation.

The practical problem here of course is that the complexities of a project may not be apparent until the project timeline has been scheduled. Barriers to change may present themselves and lead to a project running over time and this occurs in projects of any kind (e.g. building the Millenium Dome and Wembley). A “Buffer Zone” should be built into the timing of the project to account for such an eventuality. Additional resource should be identified and pre-arranged so that more people can get involved and help keep the project on course. Although this is extra work and time, if the AI project is of substantial size it is an investment that could save a significant amount of time in the long run.

Project Ownership:

This aspect of change became extremely evident following the execution of the AI projects. Some chose to adopt a leadership role and ‘own’ the AI, while others took a more team-based approach. It might makes sense, on face value, for the person who perceives the need for change to lead the project, since they are perhaps the most aware of the problem that needs addressing. However looking deeper this is not the case. Most of the project leaders who attempted to champion and lead the project were not in a position of power or authority to make key decisions to move the project forward past certain hurdles on the way (see; http://www.cemp.ac.uk/macmp/forum/download.php?id=238). Due to this, unanticipated outcomes resulted, which in this case was the adoption of the implemented solution outside of the project plan. This is a problem since the use of the solution was then out of the leader’s control and data could not be collected as planned. In another case it meant that the project leader did not have enough authority to push through various decision stages, where it was held up.

If the leader had sufficient authority within the organisation to make the decisions and be able to enforce the project’s structure and process there is likely to be no problem. When this is not the case however it becomes apparent that it is better to adopt a collaborative approach, to ensure that everyone buys into the aims and values of the project. This is more likely to lead to a situation where people adopt the plan and champion it themselves. This means that if the leader needs to drop out or leave the project for whatever reason then it is likely to continue anyway. This group cohesiveness is also likely to save time and organisation. Further more if this collaborative effort includes those in a position of power, then the project is likely to have the necessary team in place to effectively execute a plan of change.

There is also the question of skill. In same cases it might take an employee on the front line to identify a problem with process, resource etc. Yet they may not be the right person to lead the project and not have the necessary skill set to lead a project. This is where it is apparent that an instigator of change does not necessary have to lead, but relinquish control to someone who will be able to see it through, while being an advocate of the project. This will result in efficiencies gleaned through using the right staff for the right job and ensuring that individual strengths are played to. Again this is embracing mutual ownership and a collaborative effort that is less likely to fail.

The Scope of Change Attempted:

This factor relates to the issues of time and resource available, as well as project ambition. As identified, sufficient time and resource (physical and human) is required in order to execute a successful project of change or AI. It is therefore imperative that too great a change is not attempted to overstretch these elements. What is available to the project must influence whether certain problems are attempted and what the solution might be for this. If too greater scope is attempted then the change is likely to fail or put on hold. Certainly the chosen problem needs consideration on this basis. Unfortunately it is often difficult to know what might be required as a solution, when looking at the problem. The solution that meets the needs of the project may exceed the available time/ resource, yet only become apparent after significant work has been complete (see; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335). Rather than holding the project the best solution is to compromise and work on another solution that meets the needs of both the problem and resource. This might be enough to solve the problem or provide a sufficient temporary solution until the necessary resources are available to adopt the ideal solution.


It is clear that all of these factors are intertwined and vary in their impact on managing change, depending on the context in which the change is being made. The context itself is made up from all of the influential variables listed in the Wiki including those discussed here. Early consideration must be made for the above issues in order to provide a solid understanding of the microenvironment that change is being instigated within. If one of these is not planned for correctly the project will not be efficiently executed or even worse not happen at all.


A Critical Re-evaluation of My AI July 14, 2007

Posted by alwilliams in Production Analysis.
add a comment

Was I really embarking on a reconnaissance cycle or was it just another ‘action round’?
(see; June 18 2007 http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=342)

→ Reconnaissance was crucial and the largest part of the AI, which might make it seem more than just ‘reconnaissance’. However this was the most important element for my AI.

→ This stage was all about gathering ideas from internal stakeholdersand testing the infra-structure needed to embark on optimising our sales campaigns through strategic action

Concerning that it is suggested we cannot measure the effectiveness of individual sales campaigns
(see; June 25 2007: 11:42am http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=342)

→ Could not use ARPU to compare the first few sales campaigns due to the numerous variables at work that are yet not fully understood

→ Need many (up to 50??) different sales campaigns to provide enough data to start comparing them and identifying the variables that we can start to use to optimise our sales campaigns

I am confused why after mentioning ARPU you go back to using overall sales for your targets

→ ARPU was not useful at this point in time

→ Sales volumes provided the most comparable and useful metric at this stage in the enquiry

Have you discovered any more about the optimal time and length of release?

→ Not really. Of course there is the Habbo community’s and Habbo’s business perspectives.

→ The community want to be able to get hold of an item, but ensure it is as scarce as possible on the site so it is of higher value. Thus there is a balance of releasing items for a short or long period of time.

→ Cannot teaser release of 1 hour was effective at generating exceptional sales over that period of time, yet might have been counter productive in the overall sales campaign

→ Different time scales likely to be needed for different items and to maintain the hierarchy of the Habbo economy via different perceived levels of scarcity of items.

Would imagine that you can continue re-releasing rares until the demand drops below a certain base level

→ Cannot do this as it would reduce scarcity and lose the Rare’s items value

→ Might work for some items as a level of the economy’s hierarchy yet this does not create aspiration of consuming higher valued Rares

Justin’s AI Critical Review July 14, 2007

Posted by alwilliams in Production Analysis.
add a comment

There are a few areas from reading Justin’s Action Inquiry (see; http://www.cemp.ac.uk/macmp/forum/download.php?id=209) that I believe could have used extra attention and development. Although there are more issues that could have been covered, it is believed those summarised below are the most pertinent.


Primary Issues Surrounding Justin’s Action Inquiry:

1. Failure to implement the proposed solution

2. Dismissal of potentially relevant methodologies

3. Excluding the client from the AI process

4. Implementing a product rather than a process


1. Failure to implement the proposed solution:

I think this AI proposes a very useful and practical change that can be implemented fairly easily and then honed in terms of effectiveness when put into practice. This AI seems to be one where you are adding particular value by being at the end of the communication chain, by being in the developer’s role who has to deal directly with the problems associated with bad communication.  The main issue with this AI is obviously that the proposed solutions were not produced as you ran out of time. Perhaps this was due to the fact that you led the project and yet your role is not in project management nor to produce booklets that explain to the client your requirements.  This might have occurred because you were not as able at managing the project or delegating roles to ensure the requirements were met. However by adopting this project I would have hoped you had a plan of who would have produced this and planned the project timeline to ensure that the solution was produced. Instead it seems that now the project has ended and it will be shelved- perhaps permanently (as you suggest below).

the continuation of the project has (surprise surprise) slowed to a halt.

(See; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335)

As a result it is suggested that you should have instigated the change from a designer’s point of view (which is valid since you experience the resulting problems) and then recruited someone who is fully behind the project and who was in a position for it to be fully executed. It seems that perhaps you led the way, but were not able to do so to see the project through.

2. Dismissal of potentially relevant methodologies:

What interests me is your assertion that Action Research is a qualitative process (http://www.300dpi.co.uk/macmp/index.php?page=final-presentation). I reject this and not only conducted quantitative data with others (see also; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=336), but believe that this kind of data can ensure that the quantitative, ‘open’, information is correct across a sample without other people’s influence.

For example if someone in the team thought that something was a good idea, quantitative method could quickly survey everyone anonymously to find out their thoughts. This might have provided more valid data, with more frank responses, in the context of a team you know very well and where there is a ‘stage’ to perform as Goffman (1959) suggested. So, I wonder whether you might look to incorporate some form of numeric measure that would allow you to ‘prove’ the effectiveness of your project in the future to validate your findings. It seems this might really work since your employers clearly need to understand the benefit of something in order to prioritise it. If you can somehow show the effectiveness of introducing these packs through ‘hard’, numerical evidence this project may even increase in its priority and get things moving again. Perhaps this would be perceived as more conclusive than a meeting between just your team as internal stakeholders and could have included your clients or even web masters perceptions in general?

3. Excluding the client from the AI process:

…the client could not be an integral part of the early development meetings within our office, not for any overt official reason or specific issue of confidentiality – but rather our backstage team interactions rely heavily on our familiarity with each other

I agree that you cannot really let a client into certain situations of the ‘backstage’ area for them to hear how you operate and risk your professional image. Many conversations could conceivably show a weakness of the company that could either damage the perception of the company or in the worst case lose the business anyway. Yet the client does not need to be included in the meetings you describe as they do sound very informal (see; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335). There are clever ways of involving the client without them seeing this side of the internal operation (including sending a brief quantitative survey for their thoughts). Further more a company that is asking for their customer’s feedback on customer service for example may not have a weak service, but are simply trying to ensure that it is meeting continually high standards. So asking for feedback in specific interviews would have worked in my opinion if it was positioned as your dedication to exceptional service. That works in the opposite way to what you suggest and strengthens your front stage performance rather than admitting you are not very good at it.

It is at this point that I wonder whether you run out of time or did not feel that you could engage the client into what you are doing easily, which lowered the motivation of moving the project forward enough. Thus, whether excluding the client in this AI’s development was a time pressure issue rather than a deliberated one. To me it is a shame that the client was not included in the AI at all and I believe that the piece could have used some external input from the people you are designing it for.  After all this AI was embarked upon to provide clients with information and so by default they should have been included in order to service their needs as well as yours. Although it is conceded this might not be appropriate during the development stage, clients could have been probed as to whether they might need any specific information, under the guise of servicing their individual needs better (after all different clients have different levels of experiences as Justin pointed out). This would have worked at the beginning of the AI to ensure that the outcome was specifically based on the needs of the client. Although the main points of communication are likely to be known by the company certain elements or things you take for granted may need spelling out or explaining in a particular way to an outsider.

Unfortunately you did not make it to the implementation stage, but this client involvement needs to continue at this stage as well and it would be good for this to be a certainty in your mind and not just a hope as you suggest below.

…allowing the client into the process would be an insightful experience for both parties, at least at a later stage of testing and feedback, and its something we will hopefully be doing

(see; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335)

You suggest that your new office manager will be in a position to take up this project, but I wonder what impetus they will have in ensuring that the benefits and processes associated with AI are adopted.  I would still hope you keep involved in the project, even in a steering capacity, to ensure things are done correctly.  In developing this project I hope you involve the clients in some form of feedback that ascertains if they see this as valuable, as well as investigating whether there are any numerical ways of showing that the communication pack has reduced the number of i.e. follow up queries from the clients, emails you need to send back clarifying things, ‘problem’ situations that you describe that you pre-define.

4. Implementing a product rather than a process:

These things should be of utmost priority. Yet they are overridden by short-term work and other projects that have the attention of the people in charge (non-web projects that are not affected by this information pack). If we were struggling for work then I expect things would be followed up much more quickly, as it is there is always something to be working on, and jobs that come to a halt are put aside for work that needs doing ASAP.

(see Wed Jul 4 2007 9:13am; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335)

Yes moving this forward is now out of your remit, but I think that it takes someone affected by the issue and that is somewhat removed from developing it- a position you are in. You seem uncomfortable with the idea of pushing the development of this solution forward in your role, but think if this was the case that you could have looked at influencing a process, rather than something that needed producing and that relied on others. Looking at this problem you faced provides a potential reason for why you experience this and this might be because projects like this are embarked upon and then left.  This this wastes a lot of time. Could a simpler solution been looked at relating to how you communicate with clients and the process your company goes down in securing the details of the website deliverables? This might have also ensured that the solution was implemented and tested.

Two weeks after we took the job on he seemed to change his mind, after having agreed in earlier meetings to everything we had asked of him… Because we left him with nothing in writing about what he was getting, only verbal, we had no way of controlling the situation.

(see Sun Jun 01 2007 10:57 am; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335)

Here it seems that again your solution would have been an effective and professional format to provide such information. However the solution could have also taken the form of an email (perhaps pre-prepared template collaborated on by you and your boss to ensure it was done) detailing what you could do/ not do and what was needed from them instead. This kind of email is not intended to be cynical or negative, but for clarifying and ensuring everyone knows what was said and agreed. If something does not occur after a follow up email then it is clear who is at fault.  This is modifying the existing process rather than requiring resource and motivation to produce a physical piece of communication. Perhaps this kind of solution would have been more effective.  After all it is apparent that large and high value accounts are lost or abandoned and I think that, as suggested, a clear email to the client to follow up with what is needed may have worked and provided another way to have ensured the issue was addressed to some degree. Here you are lubricating the process of securing mutual understanding with all parties before moving forward.

several of my jobs are now stuck on the ‘awaiting copy’ phase. Its a morale-eroding situation.

(see Sun Jun 01 2007 10:57 am; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335)

It seems to me that this is a massively important issue that you have identified for your AI that can be ‘fixed’ (at least to a degree) quite easily by a change of process in how clients are communicated to. However if the motivation or time was eventually there to produce your original idea then this would have provided at least be a temporary solution until this can be developed and implemented.


Suggested Development of Justin’s Action Inquiry

1. Ensure that the timing of the project and resource available means you can implement your proposed solutions

2. Look how the many different methodologies might help inform different areas of your AI

3. Ensure you include the audience or relevant stakeholders when developing a project in some capacity and look for the most useful way to do so. You need to be aware of the views of the audience you are producing something for

4. You might want to look at creating or modifying an internal process rather than a physical item to solve the identified problem