Lean in project management

In general we can map the following kind attributes to lean

• Eliminate waste
• Optimize the whole
• Learn constantly
• Build quality in
• Project attributes could typically be seen 
• Complete on time
• Complete on budget
• Complete requirements

There is a clear distinction between these two. Lean is more about improvement and focus on essential only as project is about results. That makes this topic interesting - how can these complement each other.

Project management is a process to me. When looking into the lean i started to think this from Value Stream point of view.  Work packages as values stream - weak links in the stream can review the wasteful practises.

This leads to role of project manager so that instead of managing activities the project leader in lean focuses on reviewing the way that work package passes between team members.

Couple of other central topics which should/could be emphasized. The last planner concept. The person who is doing the planned work in the project - make sure he/she is involved in the planning identifying the work, talking with relevant stakeholders and has adequate powers to do the work. Continuous improvement. Pay attention to learning within the project AND keep the scoping under control.

Right tool for the job - what about the architecture

How does the architecture relate to 'project management' discussion. Well, part of the tool selection you need to identify and understand the task at hand - what are the key areas. Why discussing agile architecture here? Because I'd like to understand how a typical heavy upfront activity could be managed in lean & agile way as I am pretty convinced of the benefits of those compared to waterfall.

First of all you can use 'architectural significance' as one priorization criteria, which would put those requirements on the top of the backlog.

Another topics is the right team, meaning that in case you have an identified architectural challenge on your hands the team must be able to cope with 'agile architecture' - ok, this is nothing different from any project/development activity the right people do make the difference in any case.


Quote from Nick Malik at http://blogs.msdn.com/b/nickmalik/archive/2009/04/27/why-agile-development-requires-agile-architecture.aspx

Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort.  Agile architecture RARELY produces a detailed class model in advance.

Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself.  (think: Scrum of Scrums).  Agile Architecture nearly never produces diagrams of technical things, like the structure of a message.  Dev tools do that, from the code itself.

Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code.

Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.

Technological changes and cultural changes

In most of my change cases you can divide the project change target into two entities: Technical changes and cultural changes. It is impossible to say which one is the more challenging one as it very much relates to the challenge on hand AND the project's capability to perform i.e. what kind of skills do you have onboard.

Taking a bit general approach I could say that technological changes (systems and tools) are easier one. People need to understand the tools and related processes and you just put the focus and effort on effective training and support.

Cultural changes are more difficult to handle. First of all, in a global company you need to work on the company culture and the anthropological culture. Both can have influence on management styles, attitudes, standards etc. and they are hard to manage.  I guess that the basic tools are once again the same that can be used everywhere - user participation, communication, leadership and commitment from the top.

From personal experience I could pick up two things. First of all - get familiar with the culture which should be changed. Talk with the people, meet face-to-face, have a coffee with them.  Understanding the "unknown" helps you with your tasks. On the other hand pay attention to the change champions. Find the right people who are willing to change, how have organizational position and more preferably are mind setters in the old organization and with the CM tools convince them to do the work for you.

Remember to check that how the organization dynamics work, what role does the hierarchy play. Make sure that you understand how decisions are made - I mean really DONE.

Some reasons why people are likely to persist with their existing tools and mindsets


There are lots of material stating that human side of the change is overlooked in ICT projects - or maybe I am just reading those studies ;-)  Clegg & Walsh (2004) suggest that in many cases too little attention is paid to the social side of change. They also list some reasons why people are likely to persist
with their existing tools and mindsets:

• There are no clear, unambiguous reasons to change
• They do not trust the people telling them to change
• They are under pressure and they choose to trust in the familiar
• Replacement tools are not proven (or worse, do not exist)
• Dropping existing tools seems and feels like a failure
• Everyone else is using the same tools
• The tools are part of the group‟s professional identity (“our tools are us”)
• Use of the tools conveys power and legitimacy to their users
• The tools serve and further the interests of their users

Reflecting these topics against my own experiences

They do not trust the people telling them the change. Is very true and also a difficult topic to handle. In case you work  as a consultant and organizations, teams, projects, companies come and go you are not the person to have the trust at the beginning - you may work to gain that trust, but this is more like a stakeholder management and comms issue. You need to involve the right stakeholders, get them to "Committed" state and let them to speak on your behalf. These key persons can be from management as well as from peer group (opinion leaders).

It requires a lot of work to identify the right persons and also interpersonal skill from yourself to work out the topic with them.


Replacement tools are not proven (or worse, do not exist)
As a pro project leader you need to understand what do you have in your hands. When the tools are not proven it will create a certain risk to the project. You need to manage the risk according to risk management methods. What comes to the change management side you have  a dilemma related to the risk - if the tools are not proven you may take (case-by-case) the risk and sell the change not directly telling the target user group the possible flaws of the tools. If things go right you are clear, but this is kind of one shot case. It will be lot harder to try convincing people again once they have noticed that you are not telling the whole truth see They do not trust the people telling them to change. You may also take the honest approach and communicate where the development team is with the replacement tool, react to any feedback and try to get the things on track.

All in all this is a case where I would look into mirror and think - Do I believe into this myself? If the mirror response is No - then you may need to say to your boss that I am not the right person to lead this change.

Everyone else is using the same tools is a tough challenge. I have worked in several cases where the goal is to improve something by replacing the tool or cases where you are forced to change the tool e.g. for technical reasons. I have not found a silver bullet to solve this. Lots of cases the new tool is good for the company on average, but it is a step back for many. How to tackle that. I guess you need to dig into the "what's in it for me". This is also a typical case where you need to plan and communicate the big picture how to move will go through the whole user domain.


The tools are part of the group‟s professional identity (“our tools are us”)
...OK, I give up. How to tell the guys who maybe have developed the tools and have been using them for 10 years and the support guys sit next to the team in the same floor. Let's not forget the CM basics, but I guess in this case it would be good to talk to management, show some carrot (bonus).

Three key factors for successful project

An ICT project must have three key factors in place in order to have chances for success. The factors are: communication, a competent project manager with project experience and knowledge about the organization‟s
core business, and top management support. Change management is an important part of the general project  management but it is not enough alone if the project manager is otherwise not competent enough or other key factors for a successful project are not in place.

Source:  Master's thesis: Change management as a part of successful ICT project management
Antti Pasanen, 2009
Department of Marketing and Management
HELSINGIN KAUPPAKORKEAKOULU

This theses supports my personal experience in project management:
Communication
A competent project manager with project experience and knowledge about the organization‟s core business
Top management support
Communication - today's work is plenty of communication and I am not talking about the amount of communication but the quality of the communication - right message to right people right time and feedback loop that the message got through in a right way.

A competent project manager - what can I say in same areas you can still see thinking that project management is something anybody can do. It is mainly a mandatory thing that must be  in place and hopefully he/she does not cause lots of extra cost or hassle. However, I think just like in any other area experience is something that will ease things. Also project management must be treated as an own competence and developed systematically to reach higher standards.

Top management support - In case you don't have a killer application to roll-out you will face challenges when trying to change something. It is crucial to have management to deliver clear message supporting your activities at the same time as you need to work bottom up to clarify what's in it for me. And when the shouting gets louder it is good that you have managed your top stakeholders well and ensured their commitment. This may carry you over the hard times in the project even though pure top management support alone does not guarantee anything - at least my experience in most of the corporate cultures I have worked.

This is supported nicely by this article by sixdisciplines.com: http://www.sixdisciplines.com/_blog/The_Six_Disciplines_Blog/post/Change_Is_Inevitable_Failure_Is_Optional/

Selecting the right tool


A good starting point for the tool discussion is that the tool is "only a tool". You need to have competent people to use the tool(s). Another thing to remember in this tool decision is that when talking about agile, scrum, kanban or even pure waterfall these all tend to cover just the core layers of the work. There is a lot more in making a project successful. I mainly touch that area in the Change management topic.

How do you know which tools to apply. Well, I don't have an exact matrix how the tool evaluation is done, but
Clear target vs unclear target
Clear target and scope makes it easier to pick waterfall approach... but keeping in mind the good agile practices - keeping customer closely involved, regular short improvement cycle and working on the plan details as you move on.

• Experience vs. inexperience
• Have we done this before?
• Small change vs. big change
• Realistic schedule vs. unrealistic schedule

In a real work there are situation that you just have to live with the unrealistic schedules
I would pick up an iterative approach to reduce the risk not delivering anything