If you are managing multiple Team Foundation Server (TFS) project teams then you probably would prefer to filter the user/people selector based on project or roles. The standard list includes all users, which contains more users than necessary.
Visual Studio provides an option to modify the work item templates. You can access this option at Tools-Process Editor-Work Item Types-Open WIT From Server. Select the Team Foundation Server and Project Collection before clicking Connect. The available work item templates will appear. Next, select the appropriate template to apply the filter. In this example, the User Story was selected.
On the Fields tab, select the Assigned To field.
After selecting the field, the Fields Definition will be presented.
Click the Rules tab, which provides the filtering options for the Assigned To field.
Select ALLOWEDVALUES and click Edit. You can assign a project group with the [project] placeholder and the name. In my case, assigning the TFS project team.
Once you save the work item template, visiting a User Story and selecting the Assigned To field will display the filtered user list.
You can also export the work item template and add to TFS source control. In this case, modifying the following XML will also update the filter.
|XML |||copy code |||?|
<FieldDefinition name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="[project]\My Team" />
<HELPTEXT>The person currently working on this story</HELPTEXT>
Hopefully, this tip can save you time applying a filter to a user/people selector.
I recently met a friend and fellow software engineer to discuss his current project. We met earlier this year during my .NET Code Camp presentation. I appreciate his candid feedback and suggestions for future articles, since he is a very talented developer and fanatical baseball fan. Although I really enjoy baseball, I am more of a seasonal fan in October. He is also an advocate of the same software design principles and supporting design patterns outlined during the presentation, which I also featured in “How to design and build better software for tomorrow?” multi-part series.
The project entailed building three major back-office applications, so he assembled a development team for each application. The teams were instructed to follow the software design principles, which they all agreed were important. After several weeks, he was surprised that each team presented such different solutions. The data access layer choices were NHibernate, Linq2Sql and Entity Framework. Although all teams built web solutions, two teams selected Model-View-Controller (MVC) and the third team Model-View-Presenter (MVP). The teams also selected different Inversion of Control (IoC) frameworks, which included Spring.NET and Microsoft Unity. They also followed different validation and exception handling strategies. After he summarized the current status, he expressed his disappointment and frustration. He was obviously directing some of the blame at me. I apologized and sympathized with his frustration. After a brief baseball playoffs and politics conversation, I suggested we work together to rectify the current situation and develop a plan to get the projects back on track. He recognized the long-term impact would be detrimental to the organization, since they would be forced to maintain so many competing technologies, tools and implementations.
I am not surprised that three teams delivered three different solutions. The core principles provide guidance and promote well- designed software, which all three products exhibited. They encourage a design that meets the objectives of the organization and project, but not tightly coupled to any implementation. Change is expected. The ”How to design and build better software for tomorrow?” multi-part series demonstrated a variety of presentation, business and data access layer implementations. The same principles and design patterns were applied to console applications, WinForms and MVC. We developed concrete data access implementations using pure ADO.NET and LINQ. The core software design principles and patterns are also platform independent, so we built working .NET and Java applications.
After this explanation, he better understood the objective of the software design principles and patterns. We agreed all teams were successful and accomplished the objectives. What went wrong? How do we fix it?
The enterprise architecture is an organization-wide framework containing a collection of collaborating modules to support the organization’s needs, which is the foundation for a unified platform. This requires establishing the common infrastructure or framework promoting the same core software design principles and design patterns. I would also include the supporting processes.
The logical approach is building a common framework before launching the development of the domain-level modules, but we now have three working applications and no enterprise architecture. After reviewing the three applications, we noticed the teams built similar interfaces and abstract classes. They also share many common services and concrete implementations. These are all common framework candidates, but we were still faced with many decisions as the enterprise evolves. In the end, we decided to apply basic project management techniques and invite the three teams to participate in the sessions. We referred to the three applications as “prototypes” and discussed the technical merits of each including risk, cost and schedule assessments. The teams prepared demonstrations and discussed the technical design. Although the teams initially lobbied for their design, the project management techniques reduced the probability of a biased decision.
The following is a summary of the major decisions and foundation for building the framework.
- Presentation/User Interface - MVC3 and Razor using view models
- Business - service objects acting as the entry points coordinating the exchanges between presentation, other service objects and the data access layers
- Domain – a rich domain-driven design (DDD) supporting enterprise validation
- Data Access – persistence using NHibernate to SQL Server
- IoC – Spring.NET
After a few weeks, the enterprise team started building the common framework based on the agreed technical design. Once the framework is complete, the team will refactor the three applications to integrate the common framework. Since the team followed the core software design principles and design patterns, this task will require much less work. The Dependency Injection (DI) pattern and IoC will simplify this process, so the team can focus on building the domain modules to satisfy the needs of the organization. The project schedule was pushed slightly to the right resulting in a delay, but all is not lost. The team is confident the common framework and wealth of reusable components will enable them to accelerate the schedule and deliver the products on time. They also agree the quality will be much improved. Maybe you did not notice, but I no longer refer to them as teams. The experience not only produced a unified enterprise framework, but they are now a unified team.
In the majority of my engagements, we always plan and build a common framework. If you do not have a dedicated team to maintain the common framework then appoint members from all project teams to participate. In both cases, the enterprise team should act as the change control board (CCB) to approve or deny change requests. It is critical to ensure changes do not break existing features or modules, so following the best testing practices is essential.
When the team extended an invitation to participate in this process, I could not decline the offer. They also agreed to allow me to blog about the experience and share with the community. So…I plan to chronicle the journey and decisions along the way including plenty of code examples. Please visit again soon…
In Part I of the series, we discussed the Initiation and Planning phases of a project. In Part II, we will introduce the Implementation and Closing phases.
The project plan was the deliverable of the Planning phase, so this will be the input for the Implementation. In this phase, the project team produces the product or service. The project manager manages expectations, coordinates team members and monitors performance. The baseline provides the guideline for measuring performance, which contains information for the project constraints – scope, cost and time/schedule.
The following are some of the monitoring tools.
- Earned Value (EV) – monitoring formula including scope, cost and schedule.
- Variances – cost performance index (CPI), schedule performance index (SPI), budget at completion (BAC) and estimate at completion (EAC).
The earned value represents the value of work completed to date. You should refer to the work breakdown structure (WBS), where we defined the work packages. During this discussion, we stated the work packages are used for tracking the costs/budget. At that time, the planned value (PV) represents the budgeted cost of the planned work. If the work package budget is $100 and is scheduled to be 25% complete today then the planned value is $25 (25% of 100). The actual cost (AC) is the actual money spent.
The earned value (EV) is similar to planned value, but it is based on actual work completed and not planned. This information is best illustrated in a chart, where the actual costs (AC), planned value (PV) and earned value (EV) are presented as value over time. At a glance, you will be able to determine if the project is over budget and/or behind schedule.
The next step is calculating the variances using the EV, PV and AC. The following are a few common formulas for variances.
- Cost Variance (CV) = EV -AC
- Schedule Variance (SV) = EV – PV
You would prefer to see positive results for both formulas, which are cost savings or ahead of schedule. The following are two indexes, which provide a percentage result using the EV, PV and AC.
- Cost Performance Index (CPI) = EV / AC
- Schedule Performance Index (SPI) = EV / PV
Again, positive results greater than 1.0 represent good performance. You can find many books and articles published on Earned Value (EV) and Variances.
You continually assess and monitor the project using the various tools. In many cases, you will be faced with a decision to adjust the current course based on your assessment. The following are some of the common adjustments.
- Termination – decision should be based on sunk costs, where money already spent is a factor.
- Schedule – the most likely scenario is accelerating a schedule.
- Scope Reduction
If you can accelerate or reduce the schedule on a critical path then you can implement one of the following techniques.
- Crashing – adding more resources
- Fast-tracking – running tasks in parallel that were planned to be sequential
I have participated in several projects, where one or both techniques were introduced. The cost and risk is usually high. In my experience, crashing is subject to the law of diminishing returns. I prefer the saying “too many cooks in the kitchen” for crashing. If the existing resources are stressed then the additional burden of integrating new team members will be challenging. If planned carefully then both techniques can rebound a struggling project.
The change word usually sends shivers down your spine, but is almost unavoidable in many projects. The source of change can be the customer, team, project manager, program manager or outside stakeholders. Since change is unavoidable, preparation is key to managing changing. A configuration management (CM) plan will ensure the proper processes are followed for change. All change requests should be documented and individuals assigned to make the decisions. This is usually accomplished with a Change Control Board (CCB), so the change request is presented to the board for an appropriate decision. The submitting party should prepare the change request including the analysis representing the risk, cost, schedule and other project impacts. Configuration Management (CM) is an essential discipline for documenting, communicating and controlling changes.
We previously discussed risk, which was a key planning item. We identified and presented a strategy for each risk, so now the focus shifts to monitoring and controlling risk. At this stage, the probability or impact may change. Since the project is evolving, new risks could emerge and require additional planning requiring reserves.
Quality Assurance (QA) monitors and governs to ensure the project will satisfy the quality standards. The QA tools include quality audits, cost-benefit analysis and others.
The software development life-cycle (SDLC) also falls under the QA category. The popular SDLC models are waterfall, incremental, spiral and agile. A waterfall model is a traditional sequential approach with a significant planning phase investment. The modern agile methodologies, XP and Scrum, support and adapt to change. I have participated in a variety of projects supporting the most popular SDLC models, but more recently tailored agile methodologies are dominant. It is important to understand that a project can follow an agile methodology or just the implementation phase can be agile. I always preface agile as “tailored”, because a project and organization can follow the practices that are most beneficial.
There are several popular processes applied to SDLC as a guide to process improvements for organizations. I am familiar with the Capability Maturity Model (CMM), which is a five level model created by the Software Engineering Institute at Carnegie Mellon University. The scale is a rating 1 – 5, as you achieve greater process improvements. Level 1 is initial or starter, so the process is not very structured. Level 2 is repeatable, so the foundation processes have been established. Level 3 is achieved with the use of standardized processes. Level 4 is managed, where the metrics are published for process and quality. Finally, Level 5 is optimization using continuous process improvements. The majority of my CMM/CMMI projects have been between level 3 and 5.
I can probably continue discussing QA, SDLC and process improvements for hours. I am a huge supporter of many of the principles and models presented, but more than anything – discipline is the key to success. If you establish processes then it is essential that all team members and stakeholders are disciplined. An undisciplined team member can cause significant damage to a project – regardless of their skill level.
This is probably the most overlooked phase, since most team members are thinking about the next engagement. The administrative and contract closure are expected, but what other activities should be included in the project closing?
- Customer Acceptance – final approval
- Customer Transition – product and support shifts to customer
- Lessons Learned – discussing the good and bad
- Self-Assessment – evaluating your individual performance
The lessons learned activity documents positive and negative experiences of a project. This is helpful information for future projects, so the next team can take advantage of the positives and avoid the negatives. This could be the source of future cost and risk planning sessions, since you have historical information increasing your accuracy for estimating.
You personally should also benefit from the lessons learned and the experiences of the project. I will always perform a self-assessment of my performance during a project. If I was unhappy with the outcome of a specific situation then I will review and identify corrective actions for the future. What can I do better next time?
I hope this series provides a foundation for project management, so you have a better understanding of the core concepts when engaged in related conversations.
As software developers and engineers, we have daily project management exposure. I am not a Project Manager, because I have a passion for enterprise architecture and pure coding. I also have a desire to learn and broaden my complementary skills, so I enrolled in project management courses and training seminars. As a team lead and senior software engineer, the skills are invaluable to the project team. If you attend project meetings and scratch your head when you hear work breakdown structure, scope, critical path, float, Gantt, PERT and other alien words then a quick guide to project management terms and concepts would be helpful. So…if you seek a better understanding then this article will provide a foundation.
Project vs. Program
A project is temporary, where a start and end is understood to deliver a product or service. A collection of related projects can be combined to form a program. The program management is a higher level with a focus on coordinating the use of resources across multiple projects. Project management requires applying the appropriate skills and techniques to activities, so project requirements are satisfied.
The project constraints can be categorized as the following.
- Scope – the project work to be performed
- Cost – the resources required to successfully complete a project
- Time – the schedule
The project management challenge is balancing scope, cost and schedule. The three constraints will affect each other, so careful planning and control is required to keep the balance. If the client requests an accelerated schedule then cost will rise with additional resource demands or a scope reduction will be required. As you can see, a simple adjustment to any constraint will impact the others.
A project is usually divided into four phases.
- Initiation – defining business needs, requirements collection
- Planning – delivering the project plan
- Implementation - execution of the plan while monitoring and controlling
- Closing – resource allocation, post-mortem reviews
Initiation – Project Selection
The project go/no-go decision should involve a process to evaluate a proposal using quantitative and qualitative factors, but most importantly satisfy the organizations objectives.
The quantitative approach is primarily based on cost, where several formulas provide the decision making guidance. The following are just a few of the costing formulas.
- Benefit-Cost Ratio (BCR)
- Present Value (PV)
- Net Present Value (NPV)
The BCR compares the benefits to the overall costs using the BCR = Benefit / Cost formula. If you have a $100 return on a $50 investment then the BCR is 2:1. A higher BCR is better and less than 1 should not be accepted. This formula has many drawbacks, which includes no concept of the time value of money. Inflation is a perfect example – money received today is worth more in the future.
The Present Value (PV) formula provides the value today for future cash flows using PV = FV / (1 + i)n. The FV is the future value and i represents the interest rate as n is the number of time periods.
The final formula, NPV, compares two options using the PV formula and comparing the results. In general, the time factor will ensure multiple options can be evaluated fairly.
The formulas are examples of quantitative factors, so qualitative techniques involve bias, risk and strategic plan. These factors must also be considered when preparing a go/no-go decision.
Needs, Objectives and Requirements
A project originates from one or more needs, although not all participants will agree. The needs are identified using focus group interviews, surveys, audits and reviewing existing documentation.
The needs will evolve into objectives, which should follow the SMART model.
The requirements are the next step in the evolution of an objective. A functional requirement describes the customer’s expectation or what must happen. A technical requirement is the implementation of a functional requirement developed by the project team.
They are keys to success and a failure to deliver strong requirements will most likely negatively impact the project. The authors should remain focused on the objective of the deliverable. The functional requirements should not define the implementation.
In my experience, poor objectives or requirements are one of the leading causes of project failures. If you follow the SMART model then you will avoid this trap. I also follow the SMART model when establishing my personal objectives, so it is easier to evaluate my progress and performance during a review.
The second project life-cycle phase is Planning, where the scope and work breakdown structure (WBS), schedule, costs and resources are defined. A core project team is selected as a small group of key individuals. The major components of planning are
- Quality and Test
The planning may also include procurement and communication, but this will be driven by the project. The final deliverable is the project plan, which is the collection of all the planning components.
Scope is another term that will appear during the project life-cycle, which is the sum of the project work (i.e. services, products). At this phase, the scope planning will require the details and the result will be the scope statement.
Work Breakdown Structure (WBS)
The scope evolves into the WBS, which is hierarchical representation of the work to satisfy the project objectives. This is decomposition of the work, so smaller and more manageable items are identified. You cannot accurately estimate resources, budget or schedule without the WBS.
The work package and control account are the primary levels of the WBS. A work package should be sized to assign an individual or small team. The control accounts represent the level costs are tracked, which is generally for senior management. The WBS can be presented in a graphical chart or a traditional indented form. Microsoft Project and similar tools are available, so building and maintaining the WBS is simple using the templates.
In general, a well-designed WBS will be the source of all project management tools. A top-down design approach is the most effective method for building the WBS as you decompose the project into smaller items. Since the work breakdown does not contain item detail, a WBS Dictionary is available to collect the details about the work package.
Schedule Planning and Estimating
The next planning task is scheduling, which requires estimating time, costs and resources. There are several estimating methods and tools available to assist, which include the following.
- Program Evaluation and Review Technique (PERT)
- Wideband Delphi
The PERT process collects four time estimates per activity – most pessimistic, most optimistic and most likely. The team lead collects the estimates and applies a standard deviation calculation to produce the expected result. The formula is (most optimistic + (most likely x 4) + most pessimistic) / 6. You can use this approach for time and cost estimates. For example: you optimistically feel a task can be completed in 12 days, pessimistically in 19 and most likely in 16. The calculation would be the following.
Estimated Duration = (12 + (16 x 4) + 19) / 6
Estimated Duration = 15.8333 days
The Wideband Delphi technique requests the participation of subject-matter experts to provide a single estimate. The values are averaged and discussions begin to refine the estimate until a consensus is reached.
The 3-point estimate is an average of the same optimistic, pessimistic and most likely outcome. The formula is (Optimistic + Most Likely + Pessimistic) / 3. This formula is similar to PERT, but it does not weight the scenarios.
I have participated in several PERT, Wideband Delphi and 3-point estimating sessions for projects. The importance of estimating cannot be understated, since it will play an important role in the success of the project. It is very common for participants to simply identify the optimistic and pessimistic values and split the most likely. If you apply some thought to the estimating then you will realize this should not always be the case. I apply risk factors to my estimates, which can result in significant deviations.
At this point, we have collected the time estimates using one or more of the techniques. The next planning step is scheduling, which also includes several tools and techniques.
- Network Diagram (Precedence Diagramming Method, Critical Path Method)
- Gantt Chart
The scheduling challenge is incorporating the resource availability and productivity factors to the duration estimates. If a team member is assigned to multiple projects then you cannot allocate 100% time to a task. The experience level of a team member will impact the productivity, so you cannot expect a junior software engineer to complete a task as quickly as a senior. Finally, the third factor is the relationship or dependency of one task to another. For example: you must stand-up a web server before you can deploy the application. It is also possible that multiple dependencies could exist as predecessors and successors.
Once you have compiled your time estimates and relationships, you can calculate the earliest time an activity can start and end. This is called the forward pass. The following is a simple network diagram to illustrate the multiple forward pass calculation.
In this example, the A time estimate is 5 days. B and C will start at day 5, since A is a predecessor to the tasks. The finish day is based on the time estimates, so B is 5 and C is 10. Since the D start day is based on the completion of B and C, the earliest start is 15. This is the predecessor that finishes last, which is C.
Since we have a forward pass, we must have a backward pass to calculate the latest time a task can start and end without delaying the project completion. This will provide the values for calculating the project float time, which is the difference between the early and late end/finish dates.
After completing the above calculations, the Network Analysis will expose the project duration, float and critical path. The new term, critical path, represents the longest series of tasks or minimum duration of the project. If the tasks on the critical path do not start on time then it is likely the project will be delayed. The critical path is identified using the tasks with the lowest float value. The project manager will carefully monitor the critical path and apply resources to ensure the project remains on schedule, although non-critical path tasks are also important to the project success and must not be overlooked.
A Gantt chart is a graphical representation of the project tasks or activities depicted as horizontal bars based on a time scale. The task start, finish and durations are marked. This chart is one of the most recognized items and like the previous tasks is available using Microsoft Project. All planning tasks are simplified using tools, but the ability to calculate manually is helpful to understand the concepts.
It is great we have a project schedule, but now the focus turns to the budget. You should include the WBS work package costs as well as overhead, reserves and indirect costs. The source of the estimates can be historical information, outside consultants/estimators and your subject-matter experts. The types of cost estimates include order-of-magnitude, budgetary and definitive.
The order-of-magnitude is a preliminary cost estimate with a lower accuracy. A budgetary estimate is conducted with a high-level design available, so the accuracy is an improvement over the order-of-magnitude. A definitive estimate is completed after the detailed design is available, which is the most accurate of the three types.
A direct cost includes labor, materials and equipment costs required to complete the project. An indirect cost could include general and administrative, sales and marketing expenses. These costs will be incurred with or without the project, but must be partially absorbed at the project level. A simple cumulative cost curve will illustrate the costs over time.
The schedule and cost planning is complete, so now we must address the resources required to complete the project. This could include personnel, equipment and facilities. If your organization maintains a pool of people resources then you can work internally to identify the appropriate personnel with the skills and experience for a task. Alternatively, you can work with outside organizations to contract personnel to complete specific tasks. As a project manager, your goal is to assemble a team with the best resources available. In the end, the people will be the greatest asset and pave the way to a successful project. The following are a few common tools for resource planning.
- Roles/Responsibility Matrix
- Resource Gantt Chart
- Resource Loading Table and Histogram
- Resource Leveling
The Roles/Responsibilities matrix is a simple table aligning people to a task. The Resource Gantt chart, as explained previously, is a bar graph format. The resource loading table depicts the resource needs based on time, which feeds the resource loading histogram as a vertical bar graph illustrating resource by time. Finally, resource leveling focuses on adjustments required to meet the project objectives.
In my experience, assembling a project team requires an understanding of each candidate and aligning them with the tasks leveraging their strengths. During larger projects, I prefer the assembly-line development approach. The individuals will be segregated into smaller focus teams, where the tasks are based on traditional application tiers. This includes presentation, business and data. In general, software engineers and developers excel or prefer working in one of the tiers. When assigning team members to complete tasks including all tiers, the overall efficiency decreases as some struggle to complete tasks without experience. Again, this is my observation and experiences formulating this general approach to resource planning.
Risk is also included in the planning phase, which is an uncertain event having a positive or negative impact on the project. Risk analysis should occur throughout a project, which also includes the selection during the Initiation phase. We are most concerned with risk probability and impact. We must identify risks, perform an analysis, response planning and monitoring/controlling.
I would consider any of the previous discussed processes as a risk when you are not confident in the result. If you did not develop SMART objectives or sufficient functional requirements then this is a project risk. If you are unable to locate an important subject-matter expert to complete a task then this is also a project risk. If equipment is not delivered on time then this is a project risk.
It is not enough to just identify a risk and assign the probability of occurrence and impact. The response planning is your action to accept, mitigate, transfer or avoid the risk. When you choose risk mitigation, you are reducing the probability or impact of a risk. If you select a transfer strategy then you shift the risk to another party.
The Implementation phase is also critical, since you must continue to monitor and control risk. You can perform a great job of identifying a risk, formulating a response plan but fail to control the risk during implementation. I’ve participated in projects where this is the case, which is frustrating when you plan for the risk.
Quality and Test Planning
Finally, quality assurance and quality control are critical to your overall success. You should not sacrifice quality to meet schedule, because your reputation will suffer and negatively impact your ability to win future contracts. If you discover and correct defects early then you will significantly reduce your costs. A comprehensive Test Plan containing detailed test criteria will serve as user acceptance and provides the guidance for all participants. The project team should ensure all test criteria is satisfied prior to user acceptance testing.
I am a supporter of many agile practices, including a focus on delivering a quality product. This includes Continuous Integration (CI) and Test-Driven Development (TDD), although building unit level tests outside of the TDD concept are also very effective. Test early and often is the key! The availability of open source and commercial tools will accelerate the process to adopt the principles and your investment will improve quality. The higher your test coverage (i.e. percentage of code paths covered by your tests) and a continuous testing process will improve your quality. The cost of discovering and fixing a defect increases significantly during the later stages of the Implementation phase, so quality planning is a critical component.
The result of all the planning is the project plan, which is the guide for the Implementation phase. In Part II of the series, we will continue the project life-cycle with the Implementation and Closing phases.