Project dates aren't always arbitrary, although often they seem so. Some projects are tied to fixed dates: A regulatory event, year-end, etc. Since you’re good at what you do, you've ensured that the project plan has significant deliverables and milestones built in so that if realities change, you can still meet the critical path items. When that happens, and it will happen, the priority list needs to be dusted off. Cue the “day two” items. Maybe even some “day three” items.

We all really know that the entire concept of an “end of project” is an illusion. Once the result of the project is “complete”, it doesn't stand still. It starts evolving. I would go so far as to say that it has to evolve. We all like to say “project complete” because it looks so nice on the status sheet and on our resumes and our compensation is tied to it. But we all really know (we just can’t say it out loud) that there is always still stuff left to do and things we would change even though we just did them. Some forward-looking companies have lifecycle plans for all major systems so that there are (hopefully) no surprises down the line. It helps to end the money chase, especially when critical system enhancements or replacements are required. Evolution becomes a planned activity. For net-new products, some have embraced an entrepreneurial system: There is a pool of funding set aside and proposals compete for the funding. 

If we all start thinking just a little differently about how we view “projects”, the whole concept would give way to a more realistic way of dealing with inevitable changes in technology, markets and human interactions that drive business forward. And, at the end of the day, that’s really what it’s all about.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. 

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me

Well, your project is on the express track and it’s all systems go. You’re fast approaching the training phase in the project plan. When creating the project plan, you took the logical approach. You knew you couldn't train too early. People will forget what they've learned. However, you couldn't leave it for the last minute either. You've even put in a placeholder for “re-training”...just in case. There will be new systems and new processes. People’s job functions may be changing…in some cases drastically. Now it’s time to prepare and to start working with the training department. Wait…there’s a new surprise for you…you are the training department! Okay. After you've had a moment to accept this fact, you get to work. You line up the subject matter experts; oversee creation of the training materials (documentation, tests, cheat sheets, videos, self-running demos, etc.) and start working on a specific training schedule. You review the plan with program management and the departmental managers. You schedule some run-throughs to make sure that all the bases are covered. You pencil in “approved” dates for one-on-one hands-on sessions and some classroom sessions. You’re good to go, right? Wrong! Face it early and avoid the pain: Training is a continual process, not just a series of static events! Accept this fact and you will become a better teacher. Moreover, the trainees will actually learn to operate successfully within the new paradigm. So next time, make sure that the project plan reflects this reality from the start. For now, don’t ditch all the good work you've done on the materials and the formal sessions…just remember, there’s a lot more to it.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  10. It's over...or is it?

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me

Sometimes you know better than everyone else in the room. And, other times you don’t. When you do, you need to stand up for what you know is right…especially when time and money are at stake. How you say it matters. It can be hard to contradict the prevailing opinion. So, be sure to use tact. You may not like having to “sell” the obvious, but you still have to do what’s right for the project…and your client.

As important as it is to stand your ground, you have to know when to be flexible. You always need to keep an open ear and an open mind. Projects are collaborative efforts. The best ideas can come from unlikely sources. Through discussion, it may become clear that you don’t have all of the necessary information and your understanding is not complete. As a senior project team member, you need to know how to listen to your team and change direction if the project’s success depends on it. But you also have to know when to stand up for the client, especially when they don’t stand up for themselves. 

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  9. The train (and re-train) is coming.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

The project seems to be going smoothly and you’re feeling pretty good about it. You kick back for one second, but then notice that you have a new email. The subject line reads: “Need to address newly discovered system vulnerabilities”. Ok. Serious issue. Immediate attention is required. Just one problem: The email was sent to you...and 20 other people! Now it begins. The avalanche of responses. All going off in their separate directions. All with their seemingly own lives. It’s the dreaded forked email. The original 20 recipients start sending it to even more people. More “splinters” are popping up by the minute. You get on top of the situation quickly, corralling the messages and creating one “official thread”. Great. Crisis averted…or so you thought. But then, a few days later, “it” happens. You don’t notice at first, not until it’s too late. An email with the old subject line carries information about a completely new and unrelated problem. Your real nightmare has just begun. It doesn't take long for the confusion to rain down, especially from the program-level management. The “I thought this was taken care of” reign of terror is upon you. No matter how hard you try to explain that the issues are separate and the email chain is to blame, you are only digging yourself deeper. You could be spending weeks untangling the mess and explaining it over and over and over again. Email splintering/forking happens. It’s a fact of life. And the fallout can be toxic. Be ready for it…and, remind everyone on the team that each new subject should be in a new and separate email with a well-thought-out subject line, because today’s tiny splinter is tomorrow’s incredibly painful abscess.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  8. Be flexible...and stand your ground.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

“They’re using what? A 56kb modem?” Dust off your archeological skills, or find someone who has them because you are about to uncover the unthinkable and face one of the moments on the project you hoped would never come. You are about to find that some departments have barely progressed past stone knives and bearskins. And, you are about to hear the dreaded words: “If it ain’t broke, don’t fix it”. The only problem? It is broke and broke badly! Fortunately, you are just the person to fix it. We’ve all seen it: the server in the credenza, the hub under the desk, the piece of DOS software that is “business critical” but no one in IT seems to know anything about. The single biggest risk of legacy technology is data security. Leaky legacy systems can compromise confidential data and lead to serious financial, legal and reputational risk. To the end user, everything seems to work fine. But, you know better and need to plan the re-platforming in the most non-disruptive way possible. De-risking activities are a key component in the project plan and need to be fully understood by all stakeholders. If known ahead of time that the project includes the integration of legacy technology, a separate risk assessment for each component should be completed. If not known ahead of time, hey, that’s why they pay you the big bucks.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  7. There's a splinter in my email.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

Before a system is updated or replaced, it’s generally a good idea to know what the system does and how it does it. Your first step: Ask for the documentation. To which someone will invariably say “What documentation?” The words hang in the air as time seemingly stands still. But, you’re not concerned because you've anticipated this, right? You know what to do next: Cue the Subject Matter Experts. Of course you’ll need them from the business side and the technology side so start herding those cats now. And as this amazing journey begins, you begin to learn that neither side has all the answers you’re looking for. Face it early in the process: You will be writing the old documentation as well as the new. Look on the bright side: You will produce the best documentation that anyone has ever seen, even if it is for a system that you’re about to sunset.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  5. Time travel is in your future.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

Let me say it right up front: The project plan is your friend. So many times, technology folks seem to resent the seemingly endless time spent on project plans and project metrics. Stop fighting! When managed correctly/jointly, the project plan can be the technologist’s dream-come-true. It provides a means by which you get to tell the project leadership exactly what you think it will take to perform specific tasks. In other words, it gives you power! The project plan should never be a locked-in-stone document, slavishly adhered to at all costs. It needs to ALWAYS reflect the current state of reality. If this is not the understanding and a core value at the very top of the senior management and project leadership teams, well then, here’s your chance to step up and save the project before it even starts. Because, if the consumers of the plan look at it as the locked-in-stone gospel truth, then every change, no matter how trivial, will be treated as a crisis. Don’t fall into this trap. Expectations must be set and repeated at every opportunity. An Agile project management approach helps to mitigate these problems because it is a continuous process and should be understood as such from the project inception. Make sure that there is a change management plan in place for the plan and make sure everyone understands that change will occur and occur often, albeit in a well-managed fashion. As an adjunct, project reporting gives you a means by which forensic evidence of progress or delay can be captured and presented. More power! At the nexus of all these activities is the Project Manager. A good PM is like an orchestra conductor. The conductor typically doesn't play any instrument and didn't write the music. The conductor’s job is to coordinate and get the best performance possible. Do musicians and composers resent the conductor, the baton and the sheet music? Of course not! So why should the PM and the PM’s tools be resented as so often is the case? Understanding, appreciating and properly leveraging of all the project’s participants and the available management tools is the key to a smoothly functioning team. Let’s all take a deep breath, look in the mirror and admit it: An Agile Product/Project Vision and a Product Roadmap are simply not enough, especially for a large-scale, complex, multi-component* project where there are numerous and poorly understood integration points involving dozens of third parties. For these situations, a good project plan is an invaluable…and necessary tool.  But, remember, a bad project plan (or PM) that ignores reality is certain to kill your project and then you will be subjected to a life of un-ending misery. OK. I’m about to duck now.

*In the hundreds or even thousands.

Jeff Lowell

P.S.
When I circulated this essay for review, it generated lot of debate and drew many negative comments. A common theme regarded PM’s who fail to understand the technical complexities of the tasks and the fact that there are always many unknowns. This brings me back to having an Agile mentality where an iterative approach and reality rule at the task level. There are good PMs and bad ones. What has your experience been?  In my experience, managing the development of a single-purpose mobile phone app and re-platforming the entire operations of a bank/broker are two very different things. My experience is based on the latter…where a "dev-centric" project mindset simply is not enough. I don’t pretend to have all the answers. That’s why I’d like to hear from you.

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  5. The Missing Link.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

Corporations may not really be people (Supreme Court decisions notwithstanding) but they do behave a lot like living organisms. There are unifying systems that tie the entity together, but also specialized areas performing specific functions. But, to me, the corporate quality that most resembles organic life is adaptive behavior. Nothing in any company is static. A business is always acting and reacting. And for us, as project team leaders, to expect everything to stand still while we try to roll out our wonder-plan is unrealistic. You must plan for disruption from the start. You must try to anticipate, as best you can, what potential situations might derail your timeline or budget and have a mitigation plan in place. If you've planned your project in iterative steps and have carefully broken down the work effort into deliverable functional components, disruption will be much easier to manage. The bottom line: Businesses change or die. Sometimes the change will be at odds with your project. Accept it and work toward success within the framework of constant change. And, take heart in the fact that you’ll be considered a hero (by some) when you are able to pull it off in spite of the challenges.

Jeff Lowell

If you missed it, click here for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter:  4. A True Friend.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

If you are going to communicate the value of a project to the stakeholders, whether to the client, internally at the C-level or to the user community, you need to make sure that you are all speaking the same language. Terms and concepts must be universally understood if you ever hope to get everyone on the same page. Changing the language based on the audience may seem like a great idea but it only leads to misunderstanding and mistrust. I know it’s tempting to “dumb it down” for some audiences. Some friendly words of advice: Don’t do it. It is your responsibility as a key member of the project team to ensure that everyone understands the project goals and the roadmap and their place within the roadmap. If that means that you have to work a little harder at communicating and articulating, then know you’ll be the better for it in the long run. And, try to avoid using jargon and undefined acronyms, even if you think everyone will understand them. There’s nothing more embarrassing then opening a presentation with jargon only to have someone ask you an hour later during the Q&A session what the jargon term meant. What it means is you've just wasted an hour.

*You say tom-ay-to, I say tom-ah-to.

Jeff Lowell

If you missed it, click for the INTRO and here for #1 Change is Hard.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter: 2. Business is Organic.

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

We all know the story: The project, which will undoubtedly be the greatest thing in the history of projects, and that has been kicking around for months (sometimes years), finally gets funding approval. The goals are laid out, the sponsor signs on, the project lead starts assembling the teams and the evangelizing begins. But, once the lucky beneficiaries of this wondrous new project get wind of its impending implementation, something starts to happen…slowly at first but then with great ferocity: Resistance. The truth is every successful project means that some things will change: Processes, systems, jobs, lives. While resistance needs to be dealt with, a little humanity goes a long way. Communication (big surprise) is key. But most important: Tone matters. You will always have die-hard resisters. Part of your job is to explain the benefits to the majority in a way that engages them; building trust and credibility…which will help ensure the success of the project. It may sound obvious, but it seems so easy to forget: The end-user is your customer. And, some of them realize that your appearance means the end of life as they know it. Treat them with respect and understand that some of them are frightened.  And remember, at this point in the project, you need them more then they need you. Of course there are other places, besides the user community, where resistance can come from. But that discussion is for another day.

Jeff Lowell

If you missed it, click for the INTRO.  To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page. Be sure to catch the next chapter: 2. Parlez vous YSTIST?

I want to encourage everyone who reads this post to add comments (that tiny link at the very bottom of the post) and share their experiences as well. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  If you're interested in doing a guest post or want to present an alternative view, contact me.

Hello and Welcome!

All of us in the IT and Project Management space see a lot of "stuff" on every project. We laugh about it, we cry about it, sometimes we even talk about it. There are always many lessons learned. Many times, these lessons are dutifully written down, distributed, agreed upon and then filed away only to become tomorrow's "Oh, yeah" moments. Well folks, I’m about to do it again. We all have our personal take on what's important and place different values on the lessons we learn from our experiences. I will be sharing some of mine.

While project management, as a practice, continues to become more formalized, structural issues that plagued us in the past have given way to a saner way of doing things. Methodologies such as CPM, CCPM, ECM and now Agile give us the tools we need to effectively manage tasks and resources. But, in spite of everyone's best efforts, "stuff" still happens.

Over the next few weeks, I will be publishing some of my observations regarding a recent, very large, complex IT and business transformation project. Maybe you've had similar experiences. Maybe not. Either way, if only one person gleans a little insight or contributes to the discussion, or most important, smiles because of something I write, then I have achieved my goal.

The titles of the upcoming posts are: 

1. Change is hard
2. Parlez vous YSTIST?
3. Business is organic
4. A true friend
5. The missing link
6. Time travel is in your future
7. “There’s a splinter in my email”
8. Be flexible...and stand your ground
9. The train (and re-train) is coming
10. It’s over…or is it? 

To easily see all of the current posts in contiguous reverse order (newest to oldest), click on the "10 Observations" link under the Categories heading in the sidebar on the right side of the page.

I want to encourage everyone who reads these posts to add comments (that tiny link at the very bottom of the page) and share their experiences as well. The point here is to look fondly upon the everyday things that happen during IT projects. The things that make us shake our heads but that are important nonetheless. Oh, and please feel free to re-post and share (please use the buttons provided for LinkedIn, Twitter and Facebook).  Hopefully other subjects to explore will emerge. I might even feature guest bloggers. Interested? Contact me.

Thanks!

Jeff Lowell