Posted by Gerard Janssen terribly early in the morning: April 23rd, 2010
In our work with clients we often have discussions about the function of architecture and the role of architects. These discussion are largely due to fact that architecture does not visibly contribute to organizational goals and is perceived as a nuisance for projects. Many discussions originate from a lack of understanding of the role and place of architects in the organization. We have defined three goals of the architecture function in IT organizations: The Three C’s of Architecture. These are: Connection, Cohesion and Changeability. Taking these as the prime principles of architecture provides focus on what to do and how to position architecture in the organization.
(more…)
Posted by Gerard Janssen at around evening time: April 19th, 2010
Architecture can be divided into two categories : simple and complex.
And actually, it is the same with people. I prefer simple, humble and straightforward people. I find complex people hard to relate to, they often make a fuss about things that seem irrelevant to me and make life harder than it should be. In Holland we have a saying: “Such a person should come with a manual”. Only, I hardly ever read a manual. That is why I prefer people with a straightforward and ‘simple’ character that lack pretense and that you can take at face value. And it should be the same with architecture: let’s keep it simple. Simplicity is in fact a systemic quality that must be a driving force in architecture.
(more…)
Posted by Gerard Janssen in the early morning: July 18th, 2007
Quality assurance is too often used to just identify a lack of quality and to find deviations from the norm. This is logical in organizational cultures where responsibility is something to be managed carefully. However, wouldn’t it be better if QA would be supportive towards an overall strategic goal of improving quality? For this you need a sense of shared responsibility across the organization and its processes. Then QA can work to start improving quality by improving processes, procedures and practices, making sure to prevent problems instead of identifying them. Taking responsibility instead of shifting it. That’s proactive QA.
(more…)
Posted by Gerard Janssen terribly early in the morning: July 6th, 2007
While working on projects or embedded with a customer you always work with other people. Having a good relationship with those around you is a must for being effective. If there is no trust, one cannot know whether the other party keeps his end of agreements made. Usually a natural sense of trust emerges when working with people. But what to think of those situations where you as a consultant are treated as an outsider who is not really part of the team and is considered way to expensive anyway?
(more…)
Posted by Gerard Janssen in the early morning: June 22nd, 2007
The whole idea of executing a project is that you want to achieve something. A person or organization has goals that they want to achieve. A project is a way to coordinate the efforts towards achieving these goals. Ideally we set all of the goals before the start of the project, initiate the project and let it run to fulfill the goals. This way we would never have to discuss or question why we do the things we do. However, things have a tendency to change, even the goals might change. The question is how we deal with that.
(more…)
Posted by Gerard Janssen terribly early in the morning: June 11th, 2007
When it comes to the contents of plan there is a big difference between prescriptive and criterion based approaches. As we stated before the idea behind a plan is to provide guidance to the activities on the project. In that sense it is a sort of communication device. However, the way we use the plan determines its effectiveness.
A plan should describe how to realize the business case on which the project is based. In the criterion based approach to project management this means that the intention of the project is described, but not all activities on how to materialize the business case are specified. The essence of the plan is to explain or to translate the business case into practical guidelines and criteria on how realize the business case. Put differently, it specifies the high level requirements for the project that need to be met for the project to be deemed successful. Tom and Kai Gilb for instance like to state that approximately 10 high level requirements should be enough to give direction to a project. These requirements then are the criteria used to measure the progress and success of the project.
Posted by Gerard Janssen in the early morning: May 15th, 2007
Planning is a major aspect of proper project management. Plans are used by project management to direct the project and to monitor if the project is progressing in the right direction. To run a project successfully, you need to have a plan that describes what needs to be done. Without at least an idea of what needs to be done, it is impossible to determine if the project is successful. Hence we need a plan. However, there are many differences in the way that the project plan is used in different project management approaches. The status and role of the plan is not consistent across approaches, which can lead to miscommunication in project teams and to different views on how unexpected situations should be dealt with.
Posted by Gerard Janssen in the early morning: May 8th, 2007
The role of the project plan is a hot item in the debate on Agile versus more conventional project management styles. The status or purpose of a plan for the execution of a project is pivotal and indicative for the style and atmosphere in which a project is executed. Personally I have a number resentments towards the way in which the plan is used in traditional led projects. The most important of which is that the plan is leading and everything should be done in accordance with the plan. If something is not in the plan it cannot and should not be done, and everything in the plan needs to be executed diligently. Deviations from the plan are bad and are seen as indicators for failure of the project.
In a series of blog entries we will investigate the role of plans in a project management and try to find some answers on what the role of the plan should be, how the use of a plan affects the effectiveness of a project management approach and how it affects the way you deal with people.
As you can judge from the title, in my opinion one should not try to map the plan to the day to day reality of the project. Unexpected things will always occur and new insights will blossom. Project management must and should want to deal with that in the most constructive way, even if it was not part of the plan. The success of a project greatly depends on how one deals with unexpected events. Reality can be a real pain, especially if it does not stick to the plan.