Project Management

I’ve been holding off on this announcement until I finished the paper (mainly to make sure I actually finished it!).

I’ll be speaking at University of Texas at Dallas’ 2nd Annual Project Management Symposium on August 18-19 in Richardson, TX.  I’ll be presenting in the Project Management Methods - A (Track 3) on August 18 at 4:40 to 5:40 PM.  There are some other very interesting topics being presented…hope mine doesn’t get lost in the shuffle!

The presentation and paper is on an interesting topic (more on that in a few minutes).  My co-author, Chad Jordan, and I were able to get some interesting ideas down on paper and get it accepted for presentation at the symposium.  At some point I hope to be able to share the paper on this blog (or at least link to it).

The paper is titled “Project Management and the Stockholm Syndrome“.

The abstract is:

Project success in the world of client/vendor relationships hinges on two things: The ability of a project team to plan, manage and deliver results; and the ability to build and maintain relationships.  Most project teams understand the pitfalls of delivery but many do not realize that another pitfall is associated with building relationships. For example, what happens when project managers or other team members begin to associate more closely with the client or vendor then with their own organization?   This pitfall, which has the same characteristics as the Stockholm Syndrome, can be a significant risk for any project.

This paper addresses the topic of behaviors similar to the Stockholm Syndrome as applied to project managers and project teams. This is not an in-depth research study into the psychological effects of managing stressful projects and how these stresses might cause a ‘Stockholm Syndrome’ effect.  The purpose of the paper is to provide an overview on the syndrome and its associated behaviors and give some insights gathered from a real-world project where symptoms similar to the Stockholm Syndrome appeared and how these symptoms were recognized and overcome.

The idea for this paper came about one day when chatting with a former colleague, Gene De Libero.  Gene postulated that the affects of stress on project managers might be similar as stresses found in a hostage/captor environment.  We discussed the topic some more and decided to work on a research project. That project never really got underway, but Chad and I were able to grind out a paper on the topic.

This particular topic lends itself to future research, which is a good thing considering I’m working on a Doctorate degree

One thing that I’ve heard often is that a project manager role is a good thing for your career and will help your ascent up the ladder to more responsibility.

I’m wondering how often this actually occurs.  I’ve met a lot of Project Managers who have been PM’s for years and have had very little chance to be promoted.  Now, some of these people are perfectly happy being PM’s and don’t want to do anything else…but others are struggling with moving into higher responsibility positions.

I’ve got a good friend who’s looking to make the transition into a leadership role (she’s hoping for a Director or VP spot) and she asked for my thoughts on what she needs to do to make herself more appealing for a more senior role.

I couldn’t really answer the question…surprising I know! :)  She’s a great PM but an even better leader.  She understands business and technology and is a perfect candidate for a a senior leadership role but she’s found that companies are passing her over for advancement.  I took a look at her resume…everything looked great.    She’s personable and interviews well.  She has peer reviews and recommendations from current and previous managers…everything is the way it should…except she can’t land a job in a more senior role.

I’ve mentioned to her that she might want to start looking elsewhere because it seems as if her managers don’t want to promote her because she is skilled at what she does and they don’t want to lose a good PM.  I’ve seen this happen other places…people aren’t given a chance to move into a management role because they are ‘too good at what they do’.   Of course, that’s absolutely the wrong thing to say and do…if you have good people and they have the right skill sets to be a manager, you should move them into that role.

Does anyone have any ideas for those PM’s who can’t seem to get promoted?

I just finished reading The Strategic Project Leader: Mastering Service-Based Project Leadership by Jack Ferraro….not a bad book.

In section two of his book, Mr. Ferraro writes:

“In project management, leadership is desperately needed; leadership that is adaptable, perceptive, timely, meaningful, authentic, and unselfish.”

This one sentence sums up the core of The Strategic Project Leader’s message: Project leaders, not project processes, are the future for project management. As the first section carefully lays out, the codification and standardization of project management knowledge has created a commoditized service that can be bought and sold like any other product. However, project managers can resist the force of commoditization by adding personal value to their organizations through leadership.

Ferraro defines a new role for the project manager seeking to be the spearhead of change – the service-based project leader. As the book points out, this role of ‘Project Leader’ is an area of untapped potential in project management. This kind of leadership requires a project manager to provide service not only to a sponsor but to all the project’s stakeholders. By truly serving the needs of organizations and individuals, project leaders find themselves doing meaningful work, a factor that is linked to personal growth and great job satisfaction. Due to the highly personal and individual nature of leadership, it cannot be codified and standardized into a ‘methodology.’

The first section of the book is devoted to this idea of leadership in project management and provides guidance as to how to step up into a leadership role. However, Ferraro also introduces several critical topics not usually found in project management books. He discusses the importance of establishing trust-based relationships with clients, and putting the needs of the client first, ideas that are central to high-level project leadership.

The second section of the book provides more concrete information in the form of a ‘leadership competency framework’ that is comprised of five ‘core competencies’. This competency framework is presented in the form of a pyramid:

• Project & Program Management Knowledge, Skill & Experience
• Subject Matter Expertise
• Trust-based Relationships
• Consultative Leadership
• Courage

While knowledge of project management processes is necessary as the base of this pyramid, project leaders must move beyond this to become true consultative leaders.

The third section helps the reader create practical self-development plans – a step-by-step guide to improving leadership skills. The final section, written by Roberta Hill, provides a detailed overview of a variety of assessment methods.

Smoothly written and easy to read, The Strategic Project Leader is an indispensable guide to anyone looking to be a leader among project managers.

Interesting story in the Wall Street Journal’s Business Technology Section titled “Keeping it Simple Pays for a Champion Coder“.

The article points to the winner of a recent TopCoder Competition and points to his strategy for winning:

Roberts tells the Business Technology Blog that he spent the first hour reading through the project�s requirements and asking �at least 30 questions� of the person who wrote those requirements.

Once he understood exactly what was required, he set about designing a system that met those requirements � and nothing else. Competitors get extra points for bells and whistles, but Roberts knew that any time spent designing extra features would come at the expense of more basic functions. Instead, he focused on making sure his software worked and that he finished by the deadline, which he did � by three minutes.

This is a perfect example of the power of simplicity and software projects. It also points out how important it is to understand the requirements in your project.

Rather than just diving into the work and coding, Roberts took his time to understand the requirements in detail and got any clarifications that he felt he needed. He then set about delivering exactly what was asked for. Not More…not Less.

Roberts kept things simple while delivering a product that was of some value to the judges.

How often do we see projects fail because we try to stuff more complex requirements into a product/project? (hint: it happens a lot!).

Next time you kick off a project, think about Tim Roberts and his ‘keep it simple’ approach and see if it helps. I’m betting that it will.

This post is an excerpt of a recent paper titled “Improving Knowledge in Projects.” If you’d like to read the full paper, click here for the PDF version of Improving Knowledge in Projects.

In the project management world, a considerable amount of research exists to describe the reasons behind the success or failure of projects in the information technology space. Most of this research focuses on failures being caused lack of executive sponsorship, lack of project management methods, lack of change management processes, project scope size and/or project duration (Reich, 2007).

While these causes of failure are quite common, a large and overlooked stumbling block that causes failure in IT projects is the lack of proper knowledge management methodologies throughout the project management lifecycle.

This paper provides a brief review of the literature within the knowledge management space, and more specifically, how to manage knowledge transfer, sharing and application in projects. The main question that is initially asked (but not really answered) in this paper is that following: Can a framework containing “best practices” be developed that can be use to improve knowledge transfer and sharing in project based groups and organizations?

Brief Literature Review
Although most project management methodologies claim to be interested in knowledge management, none offer any real guidelines or practices for gathering and maintaining knowledge throughout the project lifecycle.

Disterer (2002) argues that traditional project management methods are overly concerned with efficiency and effectiveness of project team members, which in turn makes the act of capturing knowledge a lower priority during a project (Disterer, 2002). This is compounded by the fact that the knowledge needs of future projects doesn’t lie within the context of the current project requirements therefore project managers and leaders do not focus on these efforts (Disterer, 2002).

Leseure & Brookes (2004) take this claim a step further by stating that knowledge transfer is one of the largest issues in projects today when they write “Knowledge is generated within one project and then lost. Failure to transfer this knowledge. leads to wasted activity and impaired project performance” (Leseure & Brookes, 2004, p. 103). Leseure & Brookes’ designed a research project that would attempt to benchmark knowledge management practices within projects to help provide a broader and more qualitative evidence of knowledge management methods in projects. The results of this research pointed to two main areas that could improve knowledge management in projects: collecting knowledge in projects; and managing tacit knowledge (Leseure & Brookes, 2004, p. 106). By focusing on these two areas, organizations can help to improve project knowledge management.

Kasvi, Vartiainen, & Hailikari (2003) performed research on how knowledge is managed in projects and what knowledge management capabilities are required for proper knowledge management in projects (Kasvi, Vartiainen, & Hailikari, 2003). The researchers used interviews to gather data on knowledge management capabilities and practices in various organizations. The results provided interesting feedback on organizational knowledge practices in projects and led the authors to observer that “knowledge management practices were weak and unsystematic” (Kasvi et al., 2003, p. 578) and that paper documents and interactions with colleagues were the most important sources of knowledge.

Research by Karlsen & Gottschalk (2004) addresses the factors that affect knowledge transfer in projects (Karlsen & Gottschalk, 2004). The authors used surveys to gather information from project managers and organizations on knowledge transfer in projects. The survey results showed that organizational culture plays a key role in knowledge transfer within projects and should be the main area that organizations focus when looking at knowledge transfer methodologies capabilities.

Research by Slaughter & Kirsch (2006) extends the concept of the importance of organizational design and culture on knowledge management with the introduction of Knowledge Transfer Portfolios. This research, which was conducted as a field study in the area of Software process improvements, provides some very interesting ideas on organizational design and knowledge transfer and outlines the following three items as being key for knowledge transfer within organizations: Proximity, Frequency of Interactions and Relationships (Slaughter & Kirsch, 2006).

The Framework

Blaize Horner Reich, an Associate Professor at Simon Fraser University and Visiting Associate at Templeton College, Oxford University has developed a framework for knowledge management within IT Projects which seems promising. This framework, published in the Project Management Institutes’s Project Management Journal in an article titled “Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice“, proposes a three level model that addresses the following topics:

• Describes what “knowledge management in IT projects” is
• Provides a typology of critical IT project knowledge
• Identifies the top ten knowledge-based risks found in IT projects. In addition, key principles for knowledge management in IT projects are provided for use in helping build strong knowledge management capabilities within IT projects.

Reich’s framework is a good place to start as it provides a model built upon sound principles and research in the IT project space.

The first ‘level’ in Reich’s framework defines IT Project knowledge management as:

Knowledge management in the context of a project is the application of principles and processes designed to make relevant knowledge available to the project team. Effective knowledge management facilitates the creation and integration of knowledge losses and fills knowledge gaps throughout the duration of the project (Reich, 2007, p. 8).

The second ‘level’ in Reich’s framework consists of a typology of IT Project knowledge. This typology contains four distinct types of knowledge: process, domain, institutional and cultural. A brief definition of these types of knowledge follows:

• Process Knowledge: knowledge that project team members have regarding the project (tasks, methodologies, timelines, structure, etc) (Chan & Rosemann, 2001; Meehan & Richardson, 2002; Reich, 2007).
• Domain Knowledge: knowledge that a project team or member has about the industry, technology, processes, current situation, business and products (Chan & Rosemann, 2001; Reich, 2007).
• Institutional Knowledge: knowledge that a project team or member has about the organization (Reich, 2007).
• Cultural Knowledge: knowledge about the organizational culture as well as cultural backgrounds of the project team members (Reich, 2007).

The third ‘level’ of Reich’s framework consists of knowledge-based risks in IT projects. The author has listed ten risks that can affect knowledge in IT projects. These risks are:

• Lessons aren’t learned
• Flawed team selection
• Changes in the project leadership team
• Lack of knowledge of project team roles
• Poor knowledge integration
• Poor knowledge transfer within projects
• Changes in project team
• Determining “who knows what” (knowledge maps)
• Project team changes between phases
• Failure to Learn

Building Upon Reich’s Framework

Using the knowledge contained within Reich’s framework, and knowledge generated during a literature review, the following seven topics must be considered as key pieces of this framework in order for it to address project knowledge management:

• Continuous Learning / Lessons Learned - Ensures that all “lessons learned” are documented and shared throughout the organization and applied in future projects.
• Organizational Design - Develops proper project teams to ensure that the necessary knowledge transfer mechanisms can be implemented per Slaughter & Kirsch’s (2006) research
• Organizational Culture - Works toward building a culture that is pre-disposed to sharing knowledge.
• Human Capital Management practices - Covers the human capital management aspects to ensure proper motivation for project teams.
• Project Selection - Covers proper project selection as well as team member selection.
• Risk Management - Covers the aspects of project risk management as well as knowledge-based risk management as described in Reich (2007).
• Knowledge Typology Management - Covers the four types of knowledge outlined in Reich (2007) including Domain, Process, Institutional and Cultural Knowledge.

There is a considerable amount of research and thought that needs to be done to further develop this framework but an initial model can be found in Figure 1. This model provides a high-level overview of the areas that must be considered when developing project knowledge management practices.

Click for Figure 1: Project Knowledge Management Model

The model is separated into three “sections” plus feedback loops. The three sections are: Project Leadership, Project Teams and Projects. Each section contains the areas of focus for that particular project entity and outlines the areas of responsibility. A description of each section as well as the feedback loops follows.

• Project Leadership - the project leadership section covers the higher level “strategic” aspects of project knowledge management and contains Organizational Design, Culture, Human Capital Management Practices, Project Selection and Management, Risk Management and Knowledge Management.
• Project Teams - the project teams section covers the individualistic aspects of project knowledge management and contains the knowledge types (Domain, Process, Institutional and Cultural) as well as project management methods and processes.
• Projects - the projects section contains the more “tactical” aspects of project knowledge management and includes Knowledge Transfer, Lessons Learned and Continuous Interaction.
• Feedback Loops - In addition to the three sections, the model contains feedback loops that are used to ensure that continuous feedback is provided from each layer of the project knowledge management model. For example, project teams will continuously communicate with each other throughout projects regardless of which projects they are working on. Project Leadership will always be “kept in the loop” on all projects.

This framework provides an easy to recognize area of responsibility for the seven key topics that must be considered to ensure proper knowledge management in projects. As an example, let’s consider Slaughter & Kirsch’s (2006) research on Knowledge Transfer Portfolios. One of the key outputs of that research was to show that organizational design plays a key role in knowledge transfer. Using the model shown in figure 1, it is easy to see that organizational design lies solely on the shoulders of the organization’s leadership to consider.

There is still a considerable amount of research that needs to be completed in order to create supporting data to support this framework. Although not complete, the model does show areas in which organizations can begin to consider making changes to improve project knowledge management.

Conclusion
The extent of knowledge management in most project management methodologies begins and ends with the “lessons learned” document that is created after the completion of a project. This document is a good exercise, but doesn’t do much to manage knowledge during the project or ensure that knowledge is transferred between project members because project members must know to read the document to receive any value from it.

It is widely reported that project failure rates are still very high (Ahn, Joo, Cho, & Park, 2005; Owen, Burstein, & Mitchell, 2004; Pawlowski & Robey, 2004; Reich, 2007; Scarbrough, Bresnen, Edelman, Laurent, & et al., 2004). Industry research shows fifty to sixty percent of all projects are considered failures (IT-Cortex, 2007). While most research blames these failures on poor project management and/or lack of executive sponsorship (Reich, 2007), the fact that there is very little knowledge transfer and sharing between project teams has to play a key role in allowing these failures to occur.

By building a framework that can be used to help improve knowledge transfer within project teams, it is hoped that the failure rate due to knowledge-based issues will drop significantly. This framework, which still is the early development stages, should help organizations understand the underlying requirements for project knowledge management, provide best practices for knowledge management in projects and provide a way to build a corporate culture that is focused on sharing knowledge.

References

• Ahn, H. J., Joo, L. H., Cho, K., & Park, S. J. (2005). Utilizing knowledge context in virtual collaborative work. Decision Support Systems, 39(4), 563.
• Chan, R., & Rosemann, M. (2001). Managing knowledge in enterprise systems. Proceedings of the Americas Conference of Information Systems.
• Disterer, G. (2002). Management of project knowledge and experiences. Journal of Knowledge Management, 6(5), 512.
• IT-Cortex. (2007). Statistics over IT Failure Rate. Retrieved 3 May 2008, from http://www.it-cortex.com/Stat_Failure_Rate.htm
• Karlsen, J. T., & Gottschalk, P. (2004). Factors Affecting Knowledge Transfer in IT Projects. Engineering Management Journal, 16(1), 3.
• Kasvi, J. J. J., Vartiainen, M., & Hailikari, M. (2003). Managing knowledge and knowledge competences in projects and project organisations. International Journal of Project Management, 21(8), 571.
• Leseure, M. J., & Brookes, N. J. (2004). Knowledge management benchmarks for project management. Journal of Knowledge Management, 8(1), 103.
• Lytras, M. D., & Pouloudi, A. (2003). Project management as a knowledge management primer: The learning infrastructure in knowledge-intensive organizations: Projects as knowledge transformations and beyond. The Learning Organization, 10(4/5), 237.
• Meehan, B., & Richardson, I. (2002). Identification of Software Process Knowledge Management. Software Process: Improvement and Practice, 7(2), 47-55.
• Mitchell, V. L. (2006). Knowledge Integration and Information Technology Project Performance. MIS Quarterly, 30(4), 919.
• Owen, J., Burstein, F., & Mitchell, S. (2004). Knowledge Reuse and Transfer in a Project Management Environment. Journal of Information Technology Cases and Applications, 6(4), 21.
• Pawlowski, S. D., & Robey, D. (2004). Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals1. MIS Quarterly, 28(4), 645.
• Reich, B. H. (2007). Managing Knowledge and Learning in It Projects: A Conceptual Framework and Guidelines for Practice. Project Management Journal, 38(2), 5.
• Rice, M. P., Oconnor, G. C., & Pierantozzi, R. (2008). Implementing a Learning Plan to Counter Project Uncertainty. MIT Sloan Management Review, 49(2), 54.
• Santhanam, R., Seligman, L., & Kang, D. (2007). Postimplementation Knowledge Transfers to Users and Information Technology Professionals. Journal of Management Information Systems, 24(1), 171-199.
• Scarbrough, H., Bresnen, M., Edelman, L. F., Laurent, S., & et al. (2004). The Processes of Project-based Learning: An Exploratory Study. Management Learning, 35(4), 491.
• Slaughter, S. A., & Kirsch, L. J. (2006). The Effectiveness of Knowledge Transfer Portfolios in Software Process Improvement: A Field Study. Information Systems Research, 17(3), 301.

Over the last few years I’ve started noticing a trend toward specialization within the field of project management. These specializations seem to break down into the following areas:

• Administrators - people specializing in the reporting, tracking, budgeting and other administrative aspects of Project Management.
• Specialists - people who have specialized in industries or specific aspects of project management. Examples can be people who are experts in Risk Analysis, Earned Value Management experts, Portfolio Management, etc.
• Leaders - those folks who have found that project leadership is their calling. These are the folks who gladly step in and take responsibility for a project and make sure things get done.
• Technologists - focused almost solely on helping organizations implement and use technology in project management.

Most project managers can immediately place themselves into one of the three categories above (and many would actually fit into more than one…if not all three). Am I missing any specialization?

I’ve found that my particular area of interest and specialization is within the “Leadership” role of projects. A good project manager who has the administration of projects down pat can run circles around me in that regard….but I’ve found that many really good PM’s who are good at project administration tasks aren’t great at project leadership…and vice versa.

I’ve been talking with a few Project Managers that I know and they agree that they are seeing more specialization within the PM world. For more thoughts on this topic, take a look at the book titled “The Strategic Project Leader” by Jack Ferraro….I’m about four chapters into it and he seems to be saying similar things.

Which category do you fit into?

Timothy Johnson, author of the Carpe Factum blog (great blog…check it out), had an interesting St. Patrick’s Day post titled “The Luck of the Irate” where he talks about the wonderful “hit and run” managers. You know, this managers that step into a situation that they know very little about, offer their opinions and/or bark orders and then leave with the thought that they’ve “solved the problem”.

We all know managers and project managers like this…they don’t wait to find out the details…they barge in and ‘get things done’ but most times they end up confusing the issue and causing more work than needed. I’m a big believer in being hands-off as much as possible and expect my folks to bring up any issues that they need my help with…and it appears that Timothy believes this as well…he writes:

There’s a lot to be said for the finer art of facilitation as opposed to going into a conflict like a bulldozer on a steroid overdose

The “Tao of Project Management Blog” is quoted by Timothy to help make his point about using less of a bulldozer and more of a facilitator:

The wise project manager does not interfere with the work of the team unless all else has failed. Delicate facilitation is the way not sudden intervention. By using a sudden intervention the work of one or more members of the team is cast aside and they will feel violated. The team will be weakened and what may, at the time feel like a victory, is actually a failure.

Managing a team of people requires a lot of skills…being a bulldozer isn’t one of them.

I’ve been reading up on knowledge management topics (due to one of my classes being “Knowledge Management”) and have found that there is a nice subset of knowledge management research focused on managing knowledge in projects. I found this interesting and dove into a few articles that I found.

In the project management world, there is a considerable amount of research describing the reasons for success and/or failure of projects in the information technology space. Most of this research focuses on failures being caused by such things as: lack of executive sponsorship; lack of project management methods, lack of change management processes, project scope size, project duration, etc.

While these causes of failure are quite common in IT projects, one of the largest and most unrecognized reasons for failure, in my opinion, is the lack of proper knowledge management and knowledge transfer methodologies throughout the project management lifecycle.

Most projects that I’ve ever been a part of wait until the end of the project to write a lesson’s learned document. That document is a good exercise, but it doesn’t do anything to manage knowledge during the project or ensure that knowledge is transferred between project members. It also isn’t a given that anyone will ever read the lessons learned document.

Leseure & Brookes (2004) state this clearly when they write:

�Knowledge is generated within one project and then lost. Failure to transfer this knowledge�leads to wasted activity and impaired project performance� (Leseure & Brookes, 2004, p. 103).

How can project managers, team members and organizations ensure that knowledge is captured, transfered and managed in the proper ways? There seems to be a considerable amount of research on the topic.

I have a feeling that regardless of what research is done, the main focus will come down to the culture of the organization. This seems to be backed up by previous research performed by Karlsen & Gottschalk (2004) when results of a survey showed that organizational culture has the most impact on knowledge transfer in projects and should be the one area that organizations focus on when looking at knowledge transfer methodologies and knowledge management capabilities (Karlsen & Gottschalk, 2004, p. 8).

This area of research seems to be a pretty hot right now. The most recent edition of PMI’s Project Management Journal had an article dealing with this same topic and ran a great article from Blaize Horner Reich in 2007 titled “Managing Knowledge and Learning in It Projects: A Conceptual Framework and Guidelines for Practice”. Reich’s article has some interesting concepts and a framework for knowledge management in practice.

Interesting topic…at least to me Any readers have some pointers for knowledge management techniques that you’ve used in the past that might be applicable to projects?

References:

• Leseure, M. J., & Brookes, N. J. (2004). Knowledge management benchmarks for project management. Journal of Knowledge Management, 8(1), 103.
• Karlsen, J. T., & Gottschalk, P. (2004). Factors Affecting Knowledge Transfer in IT Projects. Engineering Management Journal, 16(1), 3.
• Reich, B. H. (2007). Managing Knowledge and Learning in It Projects: A Conceptual Framework and Guidelines for Practice. Project Management Journal, 38(2), 5.

Technorati Tags: project management, knowledge management

As some of you may know, I’ve talked about agile methodologies in software development in previous blog posts (see links below). The topic of Agile methods still seems to be quite hot these days and many organizations want to ‘go agile’ and many vendors sell themselves as being ‘agile’.

This is great….but many of these same organizations and vendors don’t really understand what it means to be agile and to use agile methodologies in projects. It isn’t just about having a daily scrum or developing in iterations…it also includes working with your teams and clients in a more agile way and involving those people throughout the development process. This involvement of clients is a key piece of the agile world….but some organizations just don’t get it.

I’ll use an example from my past to illustrate:

I had a vendor working for me to develop a software product. The vendor was selected based on experience, recommendations and the fact that they were user iterative development methods. I spoke to them about their iterations and methodologies and was given the rundown of how they do daily scrum meetings every morning and are very agile in their approach. This was great news to me.

The project was scoped and approved and the vendor began the development process. As part of the expectations that I set at the outset, the vendor knew that I wanted to be very involved in the iterations and they agreed to do so. The day of kick-off came and went…and then another few days went by with very little communication from the vendor (and a few emails & phone calls to the vendor from me).

A week passed with no communication….I was a little disturbed but I thought that the 4 week iterations must have the vendor extremely busy and that I’d hear from them the next week. The folloing week came and went (2 weeks since kick off) and I had heard very little from the vendor and zero insight into their progress.

During the 3rd week I was finally able to get some time with the vendor’s project manager (note to vendors: don’t ever let 3 weeks go by without speaking to your client!) and he told me that they were still in ‘definition mode’. Huh? They had the requirements for the first three iterations….why were they in ‘definition mode’? What in the heck is ‘definition mode’ anyway?

I asked the project manager what he meant by this and he said that their first ‘iteration’ was always a project definition and requirements gathering mode and then they would move into development.

I asked him to look at the scope of work and explain to me where it says that the first four weeks would be spend gathering requirements. He couldn’t find anything like that but said that it was common practice for them.

If I had the decision making powers, I would have went to another vendor…but that wasn’t my call…the decision maker liked this vendor and so we stuck with them.

After 6 months of development and many discussions about what agile/iterative methods are and questions about when I could see some output from the iterations,, we were finally able to see the ‘finished product’….and it wasn’t anything like what we asked for or needed.

My boss finally allowed me to close the door on that vendor and bring in a few software developers to tweak the product. We were able to get what we needed out of it with another two months of work.

Funny story about that vendor…they finally stopped using ‘agile’ to sell and went back to their old waterfall methods and they are doing well. They have some good people on board but they were trying to be something that they weren’t.

The point of this story? If you claim to be agile, be agile. Don’t use agile and iterative development methods as a sales tool and then try to sneak waterfall methods into the project. Truly embrace the agile methods and in turn, embrace your clients and involve them in the development process. You’ll save yourself a lot of time, money and heartache.

Oh…and if you want to use waterfall methods….go right ahead. Take the same advice to heart though and embrace your clients during the development process and your projects will turn out much better than if you try to develop in a black box.

A few more of my posts on the subject:

• Agile or Waterfall�does it matter?
• Billy McCafferty - Introduction to Scrum and Agile Development
• Agile Project Management & Product Strategy - A Case Study
• Agile Management

Technorati Tags: Agile, Iterative Development, Client Management, Project Management

I’ve been a little quite lately due to being extremely busy with the Boy Scouts of America. We recently migrated the main site from a flat file HTML system to a content managed system using Sitecore CMS. The migration was a learning experience due to Sitecore’s completely customizable architecture…but…we got it done.

The new site (you can see it at http://www.scouting.org and compare it to the old site at http://old.scouting.org) went live on Tuesday Feb 19 and has been very stable. We’ve had a few minor hiccups (broken links, etc) but overall, it’s been good. The front page is 100% html and the rest of the site is 95% Sitecore driven…the front page will continue to morph as we change the design and add a few more Sitecore driven features.

Remind me to tell you about my thoughts on Sitecore one day. For now….i’d say sitecore is a good product but don’t look for an immediate ROI upon first implementation. Sitecore takes a lot of upfront customization but delivers long term benefits.

Now that this phase is over, we are on to phase 2 with some really interesting functionality and 35+ more sites migrated into the system.

I hope to be able to get back to more regular blogging schedule soon.