This is a story about Project Management and the many pit falls, challenges and utter victories that it holds. The name of clients and team members have been changed to protect the innocent. When I accepted the job of project manager I was fresh out of three years of writing procedural code in a Apache server with a Tom Cat server piggy backing on a windows OS. Needless to say I was a developer with a deep appreciation and logging for order that I had not found at my previous employer. What I did not know is that I would be "cutting my teeth" so to speak on a project that had been dragging on for more than a year before I got there. ## What was the project and situation? When a project manager is more of a salesman than an actual project manager there tends to be long drawn out discovery processes that do not go anywhere. The manager gets told information but communicates something that lacks detail. The other problem is when things are not documented you literally end up spending time working on a foundation but then you never establish it. Its like paying for all the concrete to be shipped in, mixed and readied for pouring but then you just pour it into a ditch instead of the form you should have been building. I immediately began to read years worth of email chains and poor note taking as well a few of my own meetings with the client and the team. From that, with the help of an already fatigued lead developer we created an FRD (Functional Requirements Document). This document listed every single entity and functionality associated with that entity in the system. This was my first FRD and boy was I proud of it. The work of the lead developer was excellent and upon his recommendation we used it to actually price the project. That's right you heard me more than a year and the project did not even have a budget yet. I want to stop and thank that senior developer you know who you are. Keep up the good work sir. For reasons that are legal I can not show you the FRD though I would have it tattooed on my body if I could. ## Make sure they read it there will be a quiz later This is one of the first lessons I learned as a project manager. If you write something and hand it to the client assume they have not read it. You need to ask questions that will help ensure that you can move with confidence having everyone on the same page. Might I suggest the following line of dialog to help. - Q: Have you read the FRD I sent you? - A: Yes I have! - Q: Can I get that in writing? The fact that I did not do this would later come to cause major problems in the project. Keep in mind this is my "on the job training". ## Huge Project Huge Scope \[caption id="attachment\_157" align="alignright" width="295"\][](http://www.aaronblakeley.com/wp-content/uploads/2014/06/Pastoral-Counceling-List-Counceling.jpeg) I even began to scope new exciting features!\[/caption\] I set about making wire frames and work flows for the project. This was great! Here we are actually building the system for them. I felt like a million bucks! We worked very hard and the development whent well! After several hundred hours of development we finally had a functioning beta. I tested it and as far as I could tell there were a few workflow issues but for the most part it looked like we might be pretty close to being done. We had met and exceeded many of the features in the FRD and subsequent proposal. The problem which I was beginning to learn that I should have seen was that the scope was massive and the team on their end did not communicate as well as we did. Through no fault on there end they simply were not a development team and in truth the FRD had not been read by everyone. ## Where is feature X? This was the first sign that something was amiss. Well no the first sign that something was amiss was, one of the key players was rarely part of the meetings. They were spread rather thin on their end. Where is feature X? This is the very first pronounced sign that feature creep is setting in and it needs to be treated immediately. I had no idea what feature creep was so I rolled with the punches as best I could. We implemented a few of the smaller requests and began to scope out the larger ones. Now because of the FRD we had leeway to ask for more budget to accomplish said features. Which worked out well IF your client has read and understood the scope. In fact the image running along side here is a major feature that never got implemented because of said budget. ## How did it end? The project went on like this for nearly 2 more years. We would loose team members along the way and have to re scope and re implement major portions of functionality. \[caption id="attachment\_158" align="aligncenter" width="650"\][](https://www.lucidchart.com/documents/view/10a6d51b-0091-4fb0-974b-1fd6abb232a5) RE-FACTOR TIME\[/caption\] ## Why scope matters even when you are agile I have had many hours and sleepless nights to consider the implications this project had. Major budget, major expectations, an major lack of scope and understanding. Even in agile development scrum or otherwise scope is essential. It takes a nebulous concept and forces it to come as close to reality as possible. From there the next major lesson came forth people are precious. Sometimes we just see code, flow charts user personas and billable hours these things are data points and only illuminate the people that this will eventually serve. People have a funny way of hearing one thing and understanding another. This is why as a good project manager you must get good at communicating and the confirming that what you just communicated is understood the way it was just communicated. In turn you must get on the level of those you are communicating with both your team and the client. ## Where did it end It ended well. The client ended up with a functioning system that did what they needed. We ended up being able to close the books on something that seemed like it would never end. I have a deep love and respect for everyone that worked on that project. The client, the developer, and everyone in between if you one day read this know that what we did though it was hard and not pretty was noble and right. We are all better for it.