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.