In software/application/system development projects I get the sense (from experience) that some of the deliverables required in a project are not considered to be value-adding products. The short answer to this issue is, Cut Them. If something doesn't add value, don't waste effort, time or money doing it.
The problem that I have seen is that there is a prescribed methodology that a development team must use regardless of the scope of the project. The team automoatically programs these deliverables or products into the project without regard to what is needed. The funny thing is that this situation is the result of a pundulum that has gone too far. Ten years ago the oposite was the case. People would initiate a project without identifying any deliverables except the final software/application/system.
This area of discussion is concerned with one thing, what is the required visibility the owner of a project needs to feel comfortable with the progress of development? Ten years ago the required visibility was zero. We saw what happened. Developers built what they thought the customer wanted, and there was a separation between the user and the developer. The result was that products didn't meet the needs of the business. Additionally the cost of adjusting the product so that it met the needs was seen as too high.
In reaction to that a host of methodologies was developed to afford visibility into the process. From this sprang the Waterfall methodology which was very benchmark and gate oriented. This helped to get alignment with business requirements, but the cost was in terms of schedule and price. Waterfall project would deliver on scope but the business would have more evolved needs which typically invalidate part of the software/application/system. What I mean is that by the time the product was delivered the business need had changed.
In response to this, the Agile Rational Unified Process (RUP) was developed to get products to market faster and in greater alignment with current business requirements. I believe in and subscribe to this process. But what does it actually mean? That depends on who you ask. I will tell you what it means to me. Perhaps some inspired people will take the time to help me to think in new directions; I welcome that.
To me the Agile RUP means that there is no wasted effort and that we are building and expanding our knowledge of a particular element of the product as every step of the process. I begin the process with a statement of the Business Need. Essentially what is the problem that needs fixing. This is what typically goes into the business case which is reviewed for project budgeting. That is a post for another day.
But from the Business Need we should be able to identify the Objectives of our project. These Objectives are going to be very important later when we get to User Acceptance Testing. The Objectives must be SMART Objectives, they must be agreed upon by the owner(s) of the project or the steering (core) project team. Objectives are NOT requirements. Do not waste your time attempting to specify requirements in place of Objectives. I would suggest no more than seven.
With the Objectives in hand we will begin the process of looking at and analyzing the baseline business process. There is always a baseline business process, even on a new development project. How would we perform this activity today? Work with the right users to talk through the typical scenarios for how it works today. Identify the actors and actions. Develop Activity Diagrams, Use Case Models and Use Case Narratives.
Next, with the Baseline products in hand, focus now on what the Business Process should look like. Get people to take that King for a day atitude. What would you change... Develop Activity Diagrams, Use Case Models and Use Case Narratives.
You are now done with the first segment of your project and ready to produce the first really meaninful artifact of the project, a Concept of Operations (ConOps). Your ConOps should be based on the IEEE 1362 standard (it is a little bit nuts that I know that off the top of my head). Clause 3 identifies the baseline business process. Clause 4 identifies the things you want to change in the business process. Clause 5 identifies what the end product should look like. Do NOT let technical people write your ConOps for you. It will lose its value if you do. The ConOps is a business-specific document that should be digestable by business stakeholders. It should be in the neighborhood of 15 pages max. If you can't get it down to that size, you should think about chunking your project (another post for another day). Business people should be able to read the ConOps and say, "Yep, you got it." If they don't say that, do not leave this phase and go on to the next phase. Stay here until you get that kind of response from the business. If you don't follow this rule, you will be developing the wrong thing and ut will cost more and be more painful than it would have been otherwise.
ConOps in hand, we are going to progress and elaborate the Benchmark Activity Diagrams, Use Case Models and Use Case Narratives. How many are needed? As many as it takes to identify all normal flows through the software/application/system and enough alternate flows to provide the right visibility to the business. It could be two, or it could be two hundred. This is a balancing act that the Project Manager must feel his or her way through. These detailed artifacts are going to be really important as we use them to establish traceability through the next set of artifacts.
It is at this point that you are going to program use cases for iterations. I believe in the just in time process for this segment. If Use Case 10 isn't going to be built until Iteration 4, don't even look at it yet. Focus on the use cases involved in the current iteration. Get that segment of functionality perfected. For example if Iteration 1 is focused on Use Cases 1, 2 and 3, you are going to want to mature all of the details related to those Use Cases, as well as their requirements and design.
The Requirements Specification should be divided between the functional requirements and the non-functional requirements. Each functional requirement must be tied to an Activity Diagram, Use Case Model AND Use Case Scenario. This will be important later, trust me. I have the business stakeholders review and comment on the functional requirements and the IT stakeholders comment on the nonfunctional ones. But it is important that the business signs off on elements of the nonfunctionals as well. Uptime, data quality and the like will impact the business. They will need your help in translating these from Geek to American.
Separately I always program a special requirements document called the Data Requirements Document (DRD). The Data Dictionary, data types and ER Diagram should be reviewed by the IT stakeholders. The question to be answered in this review is, does this product allow for the type of growth this product would need if it was completely successful?
It is important to realize that you will be reviewing Requirements n number of times (where n = the number of Iterations). It sounds like more work, but it is actually less work, and I'll tell you why. Have you ever tried to review a 150 page Requirements Specification? How about a 15 page one? I would probably soak 40-60 hours into the former, and an hour or two (max) into the latter. Trying to find a 40-60 hour block is impossible, so it takes more than a month to get the big document reviewed. Whereas the mini spec, with the requirements related to Iteration 1 is out the door in a week.
With the requirements now specified, focus can shift to design. There are 2 segments to design: technical design and functional design. Don't waste the busines's time by having them review artifacts that they cannot help. They will not be able to add value to the technical design. Don't bother them with that. The Geek Squad will not be able to add value to the functional design, don't bother them with that. You should receive a segment of design that corresponds to the content in the Iteration.
Once the Iteration is delivered add a column to the Requirements Spec, Design Doc. and Use Case scenario. This is your test (verification) column. Walk through the Use Case and identify all deviations or areas where the product didn't function as anticipated. When issues are identified, try to put a note in for specific requirements that are affected as well as design sections.
Timely comments in Iteration 1 should be addressed in Iteration 2. Iteration 2 is not a separate set of functionality, it is everything Iteration 1 had plus some additional Use Cases, Activity Diagrams, Requirements and Design. You review the documents for two things; first, all comments from It 1 are addressed and It 2 functionality. Add your columns for testing and continue until you have developed all the functionalit.
Do you remember when we created those Objectives at the beginning of the project? Hand them out again. Those objectives are the test plan for your User Acceptance Test (UAT).
That is how I see it. That is the right amount of visibility I like to see ti keep things on track. What do you think?
Friday, January 30, 2009
Wednesday, January 28, 2009
Mitigating Risk
The PMBOK is a little sketchy on what exactly risk mitigation is:
Wow, what does that mean exactly? The information on page 262 is a little more informative, but let me take a moment to describe what it means to me.
This week I find myself devoting time and energy to mitigating two risks in my quest for the perfect project. My risks are unrelated to each other. The first risk is that hardly anyone took the time to review the functionality delivered in Iteration 1. I personally reviewed it and sent my comments in. The Information Security Office reviewed it at my request and performed some penetration testing. In both reviews the software was found to be of fairly good quality and performed as expected. This is good and what we hoped for.
My problem is that only one person from the business side actually took the time to review the software. This is troubling for me because I don't think we could have made it any easier for them. Detailed instructions were developed that told them how to performed the review. A list of user names and passwords was generated and deployed with the instructions. Test scripts based on the Use Cases were created. All a user had to do was follow the instructions, go into the system and perform the steps identified in the Use Case. A column was established for any notes or comments. Unfortunately only one person tested and he chose to not use the Test Script.
The risk in this area is adoption. If users of the application don't get in there and work on it, then they can't tell me which adjustments I need to make to help the application to fit better in their business process. The risk is that the project gets to the finish line and nobody has taken the time to look at it prior and they don't like it in the end. If that happens then there will be no money left to transform it into what they need and want. I hope to mitigate this by discussing the issue in the status meeting today as well as the next requirements meeting. I also plan to share the artifacts from my review with the team so that they have a model to go by for the next time.
The other risk I'm dealing with right now is in user authentication. We have a Department-Wide service that we are required to use. The problem is that establishing that connection is tricky. There are two distinct use cases for this segment. The first is in establishing a new user in the system or changing the role of a current user. In the agency we have developed an application that handles that process. There is a risk that it may not be supported and I'm working to shore that up. The other use case is when a user wants to log into the application. We send them over to the authentication service, but then what comes across the wire is a little nebulous right now. So we have to figure this one out. The good news is that I think we know what we don't know. (Does that make sense?) We know which information we are lacking and we know what we need to do to get it.
I think that the work I am doing will help to mitigate both these risks. I'll let you know.
Risk Mitigation [Technique]. A Risk Response Planning Technique* associated with threats that seek to reduce the probability of occurance or impact of a risk to below an acceptable threshhold.
PMBOK 3rd Edition, page 373
Wow, what does that mean exactly? The information on page 262 is a little more informative, but let me take a moment to describe what it means to me.
This week I find myself devoting time and energy to mitigating two risks in my quest for the perfect project. My risks are unrelated to each other. The first risk is that hardly anyone took the time to review the functionality delivered in Iteration 1. I personally reviewed it and sent my comments in. The Information Security Office reviewed it at my request and performed some penetration testing. In both reviews the software was found to be of fairly good quality and performed as expected. This is good and what we hoped for.
My problem is that only one person from the business side actually took the time to review the software. This is troubling for me because I don't think we could have made it any easier for them. Detailed instructions were developed that told them how to performed the review. A list of user names and passwords was generated and deployed with the instructions. Test scripts based on the Use Cases were created. All a user had to do was follow the instructions, go into the system and perform the steps identified in the Use Case. A column was established for any notes or comments. Unfortunately only one person tested and he chose to not use the Test Script.
The risk in this area is adoption. If users of the application don't get in there and work on it, then they can't tell me which adjustments I need to make to help the application to fit better in their business process. The risk is that the project gets to the finish line and nobody has taken the time to look at it prior and they don't like it in the end. If that happens then there will be no money left to transform it into what they need and want. I hope to mitigate this by discussing the issue in the status meeting today as well as the next requirements meeting. I also plan to share the artifacts from my review with the team so that they have a model to go by for the next time.
The other risk I'm dealing with right now is in user authentication. We have a Department-Wide service that we are required to use. The problem is that establishing that connection is tricky. There are two distinct use cases for this segment. The first is in establishing a new user in the system or changing the role of a current user. In the agency we have developed an application that handles that process. There is a risk that it may not be supported and I'm working to shore that up. The other use case is when a user wants to log into the application. We send them over to the authentication service, but then what comes across the wire is a little nebulous right now. So we have to figure this one out. The good news is that I think we know what we don't know. (Does that make sense?) We know which information we are lacking and we know what we need to do to get it.
I think that the work I am doing will help to mitigate both these risks. I'll let you know.
Monday, January 26, 2009
The Chicken or the Egg?
It is an age-old question. Which came first, the estimate or the budget? Think about it for any industry, not just IT. Anything in which work is performed experiences this problem.
Customer: "How much is it going to cost?"
Seller: "I won't know until I begin doing the work. How much are you expecting to spend?"
Customer: "I won't know until I know how much it should cost."
These two can keep going at it for hours in this circle, but the question boils down to one of estimation vs. budget. The problem is directly related to McConnell's Cone of Uncertainty. Before I begin the work, whether it is building a computer system or installing pipes, at the very beginning of the project, there are so many things that can go wrong, I have no idea how much something should cost. In the 'Cone' graphic, it is a factor of .25 to 4 times. In PMI-speak they would probably point to a Rough Order of Magnitude (ROM) estimate, which is supposed to -50% to +100%. This is all well and good, but the first question is where do I get that starting number?
The initial estimate/ budget number is extrememly important because this number, which is based on practically nothing, sets peoples' expectations about the project. I know, that isn't really fair. We shouldn't allow expectations to be set unless we have a number based on knowledge. But that is the reality. I have a couple tricks that I use to try to get around this problem. First, I don't tell anyone a number. I will say, "When we have an estimate I will be sure to let you know." That is true and safe, but it only works for a short time. The next thing I do is try to characterize the project in terms of magnitude. I will say that a project is "Big, Average or Small." This helps people to put some boundaries around the work and buys a little more time. This time that we're buying must be used wisely. You need to gather more information about the project. I recommend starting with Enterprise Architecture (EA). If your project is truly unique or new to the organization, EA should be able to tell you that. If it is not new, they should point you in the right direction for where this work has occurred elsewhere and you need to leverage that information from that previous work.
Even then, once you have knowledge upon which to base an estimate, your estimate is very likely still a best case scenario. You need to account for the risk of the project. So, let's say we performed our estimate to develop a system and it came to $100,000. That $100K is acceptable if everything goes well. How many projects are you aware of in which everything goes well? That just doesn't happen (see my previous article on the Perfect Project). So what you need to do now is identify the risks that your project could encounter. 'The business isn't clear with their requirements, I need additional integration work on the hardware platform, Critical people retire or leave the agency.' This process of risk identification must occur to identify the landscape of risks that might be felt on your project. Then these risks must be analyzed to identify the magnitude of impact if they are realized and the liklihood of them occurring. Each of these are numbers, the former in dollars and the latter as a percentage. Take the cost of the project and add the relative risks to it. So on a $100K project, I might have a risk-adjusted estimate that points me to $140K.
This risk-adjusted estimate is the starting point in terms of numbers. But until we get detailed requirements and design. Thus, I would take this $140K estimate and tell people that my ROM is $70K to $280K. I would never communicate an exact or specific number, rather only identify the range. And if someone forces you into a situation in which you need to identify a specific number, then it is $280K because that is the threshhold of resources that you may need to have available for the project. There is another stinky part on this. In the federal sector, if you don't need those funds, your project comes in at $138K, you need to kick that money back as early as possible so that they may be allocated to another project or risk sending them back to Treasury.
What we are doing during this time is to flatten out that cone of uncertainty to an estimate that fits the organizational structure. Since I'm in the government, generally, 10% is the allowable +/- for cost management (Earned Value). So, once I get my estimate into that neighborhood where I can manage to a 10% variance, I feel comfortable working to award a contract.
So what comes first? The estimate should drive the budget. But it never actually works out that way. Instead, the project selection process allows the budget to identify projects that could be performed within the budgetary constraints. All projects that are higher than the available funds in the budget are either struck or broken down into smaller components that could be performed peacemeal.
Customer: "How much is it going to cost?"
Seller: "I won't know until I begin doing the work. How much are you expecting to spend?"
Customer: "I won't know until I know how much it should cost."
These two can keep going at it for hours in this circle, but the question boils down to one of estimation vs. budget. The problem is directly related to McConnell's Cone of Uncertainty. Before I begin the work, whether it is building a computer system or installing pipes, at the very beginning of the project, there are so many things that can go wrong, I have no idea how much something should cost. In the 'Cone' graphic, it is a factor of .25 to 4 times. In PMI-speak they would probably point to a Rough Order of Magnitude (ROM) estimate, which is supposed to -50% to +100%. This is all well and good, but the first question is where do I get that starting number?
The initial estimate/ budget number is extrememly important because this number, which is based on practically nothing, sets peoples' expectations about the project. I know, that isn't really fair. We shouldn't allow expectations to be set unless we have a number based on knowledge. But that is the reality. I have a couple tricks that I use to try to get around this problem. First, I don't tell anyone a number. I will say, "When we have an estimate I will be sure to let you know." That is true and safe, but it only works for a short time. The next thing I do is try to characterize the project in terms of magnitude. I will say that a project is "Big, Average or Small." This helps people to put some boundaries around the work and buys a little more time. This time that we're buying must be used wisely. You need to gather more information about the project. I recommend starting with Enterprise Architecture (EA). If your project is truly unique or new to the organization, EA should be able to tell you that. If it is not new, they should point you in the right direction for where this work has occurred elsewhere and you need to leverage that information from that previous work.
Even then, once you have knowledge upon which to base an estimate, your estimate is very likely still a best case scenario. You need to account for the risk of the project. So, let's say we performed our estimate to develop a system and it came to $100,000. That $100K is acceptable if everything goes well. How many projects are you aware of in which everything goes well? That just doesn't happen (see my previous article on the Perfect Project). So what you need to do now is identify the risks that your project could encounter. 'The business isn't clear with their requirements, I need additional integration work on the hardware platform, Critical people retire or leave the agency.' This process of risk identification must occur to identify the landscape of risks that might be felt on your project. Then these risks must be analyzed to identify the magnitude of impact if they are realized and the liklihood of them occurring. Each of these are numbers, the former in dollars and the latter as a percentage. Take the cost of the project and add the relative risks to it. So on a $100K project, I might have a risk-adjusted estimate that points me to $140K.
This risk-adjusted estimate is the starting point in terms of numbers. But until we get detailed requirements and design. Thus, I would take this $140K estimate and tell people that my ROM is $70K to $280K. I would never communicate an exact or specific number, rather only identify the range. And if someone forces you into a situation in which you need to identify a specific number, then it is $280K because that is the threshhold of resources that you may need to have available for the project. There is another stinky part on this. In the federal sector, if you don't need those funds, your project comes in at $138K, you need to kick that money back as early as possible so that they may be allocated to another project or risk sending them back to Treasury.
What we are doing during this time is to flatten out that cone of uncertainty to an estimate that fits the organizational structure. Since I'm in the government, generally, 10% is the allowable +/- for cost management (Earned Value). So, once I get my estimate into that neighborhood where I can manage to a 10% variance, I feel comfortable working to award a contract.
So what comes first? The estimate should drive the budget. But it never actually works out that way. Instead, the project selection process allows the budget to identify projects that could be performed within the budgetary constraints. All projects that are higher than the available funds in the budget are either struck or broken down into smaller components that could be performed peacemeal.
Thursday, January 22, 2009
The Problem with the Project Charter
When you consider the PMBOK, creating the Project Charter is one of the first things you do on a project. But look at the work to develop a Project Charter, Table 3-1 of the PMBOK 3rd Edition, the inputs are the contract, the Statement of Work, the enterprise environment and organizational processes. Then, I am not expected to create my Work Breakdown Structure WBS until even later in the process. I really like "Rita's Process Chart" (Rita Mulcahey) to put these activities in order. If you don't have her book sitting right next to your PMBOK, you should.
Do you see the problem? I have a contract before I know what the work is supposed to be performed AND I have a contract before I know how much it should cost. Maybe in the commercial sector this level of squishy-ness in Statements of Work can be tolerated, but in the government, this cannot occur.
Additionally, government contracts more than $100,000 must have an Independent Government Gost Estimate (IGCE). This Powerpoint gives a great overview for that process.
Do you see the problem now? If I was to follow the Project Management processes as identified by the PMBOK, I would be violating regulations and policy. But I challenge anyone to find a Contracting Officer who will award a contract without both a good understanding of the work to be performed and a reasonable baseline from which to review proposals. Thus we are left with a problem. How do we get the information we need to award a contract AND complete a Project Charter? The simple answer is to abondon or amend one or the other process. But I would caution against that. Let's see if we can be pragmatic and meet both objectives.
Steve McConnell, the Microsoft developer talks about the "fuzzy front end" as
But we can't short change this part of the process. You must have a good understanding of the work to be performed in order to create a Statement of Work that meets the requirements of the Federal Acquisition Regulations. I believe that the best way to do this is to actually decompose the work to be performed and develop the WBS. The hard part is that there is a cost to doing this. Thus you are essentially incurring project costs really before you have a project. That is a risk that you must consider and deal with as an organization. This type of work is basically seed money, or start-up money. But you have to be careful as well or you'll spend all your time working on this part of the process and not managing the development portion.
However, once you break down the project into its constituent parts you will find that it is only one more step to generate your IGCE. You have the WBS, either in MS Project or in Excel, create a column for level of effort (I usually use hours) and then add a column for Rate (cost per hour). The final column multiplies the two to find a cost for that item in the WBS. Once you total your costs you should have a reasonable bottom-up estimate based on the work to be performed.
I would very strongly suggest that you get as many eyeballs on your WBS and estimates before calling it "Final" and sending it to the Contracting Officer. You should have Project Managers review it to identify areas in which you didn't identify work, especially in the areas of Planning, Quality Assurance and Quality Control. You need to review all of it with the subject matter experts to do two things, first, that they agree you have identified ALL of the work they expect to be performed (didn't leave something out) and they will be able to draw upon resources needed to pay for this work. This is the painful process of getting everyone's expectations in alignment. (But don't allow the elements necessary for PM visibility to be removed, you NEED that in order to keep the project on track.) Finally, make sure you get the infrastructure people to consider the WBS and estimates as well. The platform, hardware and networking costs are often overlooked and can be expensive.
Keep refining the WBS and costs until everyone is in agreement and able to support the final numbers. This means that you are indeed performing some of the work out of order with the PMBOK, but you will be ahead of the game, not behind.
I'm sure I'll be writing more about these topics over time.
Do you see the problem? I have a contract before I know what the work is supposed to be performed AND I have a contract before I know how much it should cost. Maybe in the commercial sector this level of squishy-ness in Statements of Work can be tolerated, but in the government, this cannot occur.
Statements of Work (SOWs). All Statements of Work shall include the work to be performed; location of work; period of performance; deliverable schedule; applicable performance standards; and any special requirements (e.g., security clearances, travel, special knowledge). To the maximum extent practicable, agency requirements shall be performance-based statements.
FAR 8.405-2(b)
Additionally, government contracts more than $100,000 must have an Independent Government Gost Estimate (IGCE). This Powerpoint gives a great overview for that process.
Do you see the problem now? If I was to follow the Project Management processes as identified by the PMBOK, I would be violating regulations and policy. But I challenge anyone to find a Contracting Officer who will award a contract without both a good understanding of the work to be performed and a reasonable baseline from which to review proposals. Thus we are left with a problem. How do we get the information we need to award a contract AND complete a Project Charter? The simple answer is to abondon or amend one or the other process. But I would caution against that. Let's see if we can be pragmatic and meet both objectives.
Steve McConnell, the Microsoft developer talks about the "fuzzy front end" as
the time before the project starts, the time normally spent in the approval and budgeting process. It's easier, cheaper, and less risky to shave a few weeks or months off the fuzzy front end than it is to compress a development schedule by the same amount. But it's not uncommon for a project to spend months or years in the fuzzy front end and then to burst out of the starting gates with an aggressive, often unattainable schedule.
But we can't short change this part of the process. You must have a good understanding of the work to be performed in order to create a Statement of Work that meets the requirements of the Federal Acquisition Regulations. I believe that the best way to do this is to actually decompose the work to be performed and develop the WBS. The hard part is that there is a cost to doing this. Thus you are essentially incurring project costs really before you have a project. That is a risk that you must consider and deal with as an organization. This type of work is basically seed money, or start-up money. But you have to be careful as well or you'll spend all your time working on this part of the process and not managing the development portion.
However, once you break down the project into its constituent parts you will find that it is only one more step to generate your IGCE. You have the WBS, either in MS Project or in Excel, create a column for level of effort (I usually use hours) and then add a column for Rate (cost per hour). The final column multiplies the two to find a cost for that item in the WBS. Once you total your costs you should have a reasonable bottom-up estimate based on the work to be performed.
I would very strongly suggest that you get as many eyeballs on your WBS and estimates before calling it "Final" and sending it to the Contracting Officer. You should have Project Managers review it to identify areas in which you didn't identify work, especially in the areas of Planning, Quality Assurance and Quality Control. You need to review all of it with the subject matter experts to do two things, first, that they agree you have identified ALL of the work they expect to be performed (didn't leave something out) and they will be able to draw upon resources needed to pay for this work. This is the painful process of getting everyone's expectations in alignment. (But don't allow the elements necessary for PM visibility to be removed, you NEED that in order to keep the project on track.) Finally, make sure you get the infrastructure people to consider the WBS and estimates as well. The platform, hardware and networking costs are often overlooked and can be expensive.
Keep refining the WBS and costs until everyone is in agreement and able to support the final numbers. This means that you are indeed performing some of the work out of order with the PMBOK, but you will be ahead of the game, not behind.
I'm sure I'll be writing more about these topics over time.
Monday, January 19, 2009
The Quest for the Perfect Project
I'm starting this blog with the hope that one day I will reach the finish line and look back and find that I have managed the perfect project. It is an elusive catch, this perfect project, but every day I get a little closer to finding it.
So I'll start with a little context. I am an IT Project Manager working directly for the government. I'm not a contractor, though I was years ago. This is an important distinction because PMs who work as contractors only see about two-thirds of the overall work. There is a lot of work that goes on in what Steve McConnell calls the 'fuzzy front-end'. While I'm not a big fan of all of McConnell's work, I tend to agree with him on this point. Contractor's become involved after two significant events have occurred, 1. Money has been budgeted to the project, and 2. A Contract has been awarded.
I know that contractors will claim that they have to develop a proposal and generate their bid. I understand that there is cost and work in there, but these are time-boxed elements. That means they aren't too fuzzy. The development of the business need, quanitification of work to be performed, and the number of people who must sign off each step of the process is almost always unknown work that takes forever. Suffice to say, I will touch on the fuzzy front end frequently.
The Next aspect centers around the responsibilities of the Contract Officer Representative (COR). This work represents the work to write the Statement of Work (SOW) or Statement of Objectives (SOO), develop an Independent Government Cost Estimate (IGCE), develop a Quality Assurance Surveilance Plan (QASP), market research, contract types, Chair the Technical Evaluation Panel (TEP) and write the Technical Evaluation Report (TER). Often times writing a Best Value Analysis is part of this work as well.
After project kick-off we dive in to Project Monitoring and Control. It is here that you better have a good grasp of all the PMI PMBOK functional areas. Weakness in any single area could sink a project. I will probably pay too much attention to Management Plans because I think too many people don't pay any attention to them. If your project doesn't have managment plans for things like scope and risk, stop now.
I will also have to delve into some of the more geeky aspects of IT development. Specifically in the Software Development Lifecycle (SDLC) because the deliverables you receive should not just be to check a box. They should help to propel your project forward. If your deliverables aren't doing that, then you need to think about what kind of visibility you need into the project to know that it is going well or to take corrective action if it isn't. I will definitely talk about iterative development and how to identify the pretenders from the professionals.
I will very likely focus on an area that is often overlooked in Project Management, adoption. Too frequently training, and user manuals are cut out of a project. I know that it isn't done on purpose. But there is work in those activities and just because you received software that passes some test doesn't mean the project is over. Customers are paying for a product that helps the business. They aren't paying for something that sits on a shelf somewhere. If you build the tool exactly to spec and nobody uses it are you successful? I would say no. To pass your PMP exam, say "Yes". But I think the work isn't done until adoption has been achieved.
Finally, work still isn't done until we have had a chance to hold a lessons learned meeting and identify areas for improvement for next time. I like to trick it out and hold a full-fledged Post-Implementation Review (PIR). It is only after that meeting that you can sit back and say that it is done.
These are the areas I hope to cover to share my experience with the world and help the profession of Project Management. I can't guarantee that I'll post every day, but I'll try to get something every week.
-Tipy
So I'll start with a little context. I am an IT Project Manager working directly for the government. I'm not a contractor, though I was years ago. This is an important distinction because PMs who work as contractors only see about two-thirds of the overall work. There is a lot of work that goes on in what Steve McConnell calls the 'fuzzy front-end'. While I'm not a big fan of all of McConnell's work, I tend to agree with him on this point. Contractor's become involved after two significant events have occurred, 1. Money has been budgeted to the project, and 2. A Contract has been awarded.
I know that contractors will claim that they have to develop a proposal and generate their bid. I understand that there is cost and work in there, but these are time-boxed elements. That means they aren't too fuzzy. The development of the business need, quanitification of work to be performed, and the number of people who must sign off each step of the process is almost always unknown work that takes forever. Suffice to say, I will touch on the fuzzy front end frequently.
The Next aspect centers around the responsibilities of the Contract Officer Representative (COR). This work represents the work to write the Statement of Work (SOW) or Statement of Objectives (SOO), develop an Independent Government Cost Estimate (IGCE), develop a Quality Assurance Surveilance Plan (QASP), market research, contract types, Chair the Technical Evaluation Panel (TEP) and write the Technical Evaluation Report (TER). Often times writing a Best Value Analysis is part of this work as well.
After project kick-off we dive in to Project Monitoring and Control. It is here that you better have a good grasp of all the PMI PMBOK functional areas. Weakness in any single area could sink a project. I will probably pay too much attention to Management Plans because I think too many people don't pay any attention to them. If your project doesn't have managment plans for things like scope and risk, stop now.
I will also have to delve into some of the more geeky aspects of IT development. Specifically in the Software Development Lifecycle (SDLC) because the deliverables you receive should not just be to check a box. They should help to propel your project forward. If your deliverables aren't doing that, then you need to think about what kind of visibility you need into the project to know that it is going well or to take corrective action if it isn't. I will definitely talk about iterative development and how to identify the pretenders from the professionals.
I will very likely focus on an area that is often overlooked in Project Management, adoption. Too frequently training, and user manuals are cut out of a project. I know that it isn't done on purpose. But there is work in those activities and just because you received software that passes some test doesn't mean the project is over. Customers are paying for a product that helps the business. They aren't paying for something that sits on a shelf somewhere. If you build the tool exactly to spec and nobody uses it are you successful? I would say no. To pass your PMP exam, say "Yes". But I think the work isn't done until adoption has been achieved.
Finally, work still isn't done until we have had a chance to hold a lessons learned meeting and identify areas for improvement for next time. I like to trick it out and hold a full-fledged Post-Implementation Review (PIR). It is only after that meeting that you can sit back and say that it is done.
These are the areas I hope to cover to share my experience with the world and help the profession of Project Management. I can't guarantee that I'll post every day, but I'll try to get something every week.
-Tipy
Subscribe to:
Comments (Atom)