jump to navigation

What is the “n body problem”, and what does it mean for software project management? June 23, 2009

Posted by HubTechInsider in Project Management.
Tags: , , , , ,
add a comment

It can be shown that for n project team members, there are [ n (n-1) / 2 ] possible working relationships. These working relationships grow with increased project team size as the aforementioned polynomial function shows. Of course, any of these working relationships are in danger of deteriorating, and the ones that are working out great are not necessarily transitive. For example, just because Tom and Wendy work great together, and Wendy and Susan work well together, it does not follow that Tom and Susan will work well together.

Further complicating these working relationships are externalities such as intercultural differences and outsourcing of project resources and pieces of the project work.

As bluesman Robert Cray would say: “Too many cooks are gonna spoil the stew” – or, as Fred Brooks of The Mythical Man Month has said in the central thesis of this classic software development text: “adding manpower to a late software project makes it later”.

The above factors are important to consider as a Project Manager. Poor team chemistry can ruin your chances to overcome the traditional project constraints of time, budget and resources even if your project team has at its disposal high quality technical talent.

The success of your project depends on both the quality of the talent on your project team and the manner in which that talent is engaged on your project.

It is currently fashionable for employers to surmise that a project’s success is only dependent upon the technical skill of the project team members. This is far from the truth, although a pleasant fiction for human resources and senior management.

As a Project Manager, you need to possess a wide range of people skills including team building, negotiation techniques and natural affability, you must be a master communicator, you must understand human behavior and team building and dynamics, you must be a great motivator and have innate knowledge of how to create and enhance esprit de corps.

Even the most highly technical situations are governed by human relationships and human nature. Your technical abilities and credibility as a technician carries weight with management and your project team members, certainly, but it is not your primary purpose as a Project Manager to serve as a technical resource, and all the technical skill in the world won’t save you if you can’t “Herd cats”.

The special challenges of software development will  rear their ugly heads in the midst of this, imposing their will upon the challenges of management of human teams. Only a skilled team, skillfully managed, can achieve success in most software development project situations.

“Good bow, hard to bend. Good horse, hard to ride. Good man, difficult to lead well”


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Eight ways to tell if your project team is on the way up or on the way down June 21, 2009

Posted by HubTechInsider in Project Management, Uncategorized.
Tags: , , ,
2 comments

In my professional roles leading software development teams, I have found that how Project Managers interact with their project team says not only alot about them as leaders, but also speaks volumes about the state of the organization itself. There is a dynamic lifeblood of personal relationships and interactions at the heart of a software development team that is an interesting take on leadership and team behavior. Your project team is either on the way up, or it is on the way down. In like fashion, your organization is either on the way up, or it is on the way down. Not every sign is easily recognizable at the time for what it really represents in terms of the direction your project team is heading.

 

A project team and an organization’s decline is like a disease: it is harder to detect but easier to cure in the early stages, and easier to detect but harder to cure in the later stages. Your project team and the encompassing organization may appear to be strong on the outside, but savvy insiders may be able to comprehend that your team is on the cusp of a dangerous and fatal fall off the cliff.

 

I have had the benefit (as I view it; Some would say curse) of having watched project teams in several different organizations and multiple industries. But it was easy to write about the below eight indicators because the signs tend to be the same regardless of the company and industry. In my role, you need to foster the good kind of environment where your project team can feel that the individuals are gelled into a cohesive unit that is winning. This feeling, rarely experienced, is like magic, and when a project team is hitting on all cylinders, each individual is capable of contributing their best to the endeavor at hand and feels like they are part of something special. Do your best as a Project Manager or team leader to foster this type of environment. Watch closely the eight key performance indicators I write about below and see how your current (or past) project teams have reflected which direction they are / were traveling in. You are either on the way up, or you are on the way down.

 

1. How is reality faced? – A team on the way down will shield the business owner or project sponsor from unpleasant facts – fearful and trepidacious, expecting criticism and penalties as a result of exposing rough realities. A team on the way up will constantly be exposing harsh realities: “Hey, man, look at this — this sucks hard…we got to fix this, and now”. Team members of a team on the way up will always bring forth these types of facts, as their project manager / team leader will never be critical of those who bring these ugly facts to life, feeling they need to be discussed and rectified.

 

2. How do project team members assert and support their opinions? – In a team on the way down, project team members will assert their opinions strongly, but will not provide data or evidence needed to form a strong and compelling argument. In a team on the way up, team members readily offer up solid data, evidence and bring logical argumentation skills to the discussion.

 

3. What style does the Project Manager use? – If the Project Manager or Project team leader uses a very low questions-to-statements ratio, and avoids critical input and allows sloppy reasoning and unsupported personal opinions to circulate in meetings, then your team is probably on the way down. However, if your PM or leader employs a Socratic style, using a high questions-to-statements ratio, challenges people and pushes for penetrating insights, then your team is probably on the way up.

 

4. How does the team coalesce behind decisions? – If team members grudgingly acquiesce to a decision but do not unify behind it or even work behind the scenes to undermine the decision ex post facto, then your team is on the way down. Teams on the way up will unify behind a decision once it is made, and work to make it successful, even if they did not initially agree with it.

 

5. How does the team give credit to each other? – Teams on the way down will seek as much credit for their own part of the job as possible for themselves, often not even noticing that this style seldom results in the confidence and admiration of their peers. In a team on the way up, project team members will credit others for success, and they find that this tendency will result in the admiration of and confidence from the other project team members.

 

6. Do team members need to look smart in front of each other? – In a team on the way up, project team members will argue to look smart or to further their own particular interests within the organization, but in a team on the way up, team members’ arguments and debates are all geared towards finding the very best answers to the problems and issues the project team is facing. Nobody worries about “Looking smart” in a team on the way up, because they have internalized that old saying: “Being smart’s alot like being ladylike: if you have to say you are, you probably aren’t”. Nobody in the team on the way up wants to look cool – they want to be cool.

 

7. Does the team conduct ‘post-mortems’, and how? – In a project team on the way down, culprits are sought for blame rather than in a team on the way up, where autoposies are conducted in order to mine wisdom and learning for the next time around or to make sure that the misstep results in a learning experience. Otherwise, a mistake is a mistake made twice. Project teams on the way up don’t have time to blame team members – they are too busy moving forward with the next items of business.

 

8. How about results? – Teams on the way down, unsurprisingly, often fail to deliver great or even good results. They spend alot of time blaming either individual team members or outside factors for setbacks and failures. A team on the way up, in contrast, is comprised of individual team members who are all delivering exceptional results, but in the case of mistakes, setbacks, and errors, each team member accepts full responsibility on their own and learns from the mistakes. The project team on the way up fosters this environment which enables each individual team member to feel comfortable doing so.





Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.





About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

What is “management by walking around”? June 13, 2009

Posted by HubTechInsider in Agile Software Development, Management, Project Management, Uncategorized.
Tags: , , , , ,
4 comments

Sometimes also called “Management by walking around” or MBWA, management by sight is a management strategy that can and should be integrated into any management style or approach. It is very people-oriented and it requires managers to be visible and interact heavily with project team members. Interactions at all levels of the project team foster the quick and efficient gathering of information about the project and the project team members.

Management by sight is very direct and the manager practicing it utilizes observation and visibility to conduct project analysis and project leadership, to monitor the situation, and to provide control when necessary.

I have had a great amount of success using this management technique and I thought I would share with you twelve guidelines for MBWA which were shared with me by @sjohnson717 on Twitter in response to this original MBWA post. These tips are great and I recommend following them when using this very simple and effective management technique.

Simple and effective management techniques are what every manager needs more of these days!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

 

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

management, mbwa, management by walking around, it management, it, information technology, project management

Twelve Tips for Agile Project Planning and Estimating June 12, 2009

Posted by HubTechInsider in Agile Software Development, Project Management.
Tags: , , , , ,
5 comments

Agile planning differs from the traditional software project management approaches by having as its central purpose the discovery of an iterative, optimal solution to the main product development constraints of what requirements in what timeline and with what resources.

The Agile project planning approach succeeds where more traditional planning and estimating approaches for software development projects have failed in that Agile plans focus on features rather than tasks, re-planning occurs frequently, plans are developed at different levels (portfolio, product, release, iteration, day) and because the size of a project is treated as separate from the duration of the project’s timeline, which is derived from the project team’s velocity through the decided-upon project size. Small numbers of requirements in each iteration of working software keeps work flowing, and work in progress is eliminated at the end of each iteration. Progress of the project team is measured at the team, rather than the individual level and uncertainty is acknowledged as a fact of life and is planned for accordingly.

For all of the above reasons, here are twelve tips for Agile project planning and estimating:

1. Keep everyone on the team involved – Buy-In, or real commitment, from every member of he project team is vital to the success of the project. For example, the estimation of the project is an activity that should involve all members of the project team, while only very particular tasks such as prioritization of requirements should be the primary responsibility of the product owner or an individual project team member. The more work is shared by the team, the more victories the team will have to share.

2. Plan on at least three levels – Release, Iteration and Day. Each of these three plans has a different time horizon with a different level of granularity, and each serves a different purpose in overall project planning. Do not fall into the trap of thinking that an iteration plan is a substitute for a release plan, or vice versa. There are Agile Strategy, Portfolio, Product, Release, Iteration and Day plans. Each project team such plan on at least the Day, Iteration and Release levels consistently.

3. Separate project size and project duration by using different measurement units for each – An effective technique for doing this is to estimate the project’s size in “Story Points”, or arbitrary numerical values assigned to requirements with the agreement of the entire project team and translating the project size into duration using velocity. This has the added benefit of having he project team speak of the seperate concepts by always using different terms of measurement for each when speaking amongst themselves and others outside the project team.

4. Uncertainty should be communicated by using either the date or the iteration’s functionality – Use the primary fixed constraint to express the uncertainty that all well-laid project plans must express in the midst of an uncertain world to express this uncertainty. If the number of software requirements and application functionality to be included in the iteration is fixed, then express your uncertainty as a date range: “We’ll finish in the second quarter” or “We’ll finish in between two and five iterations”. If the iteration release date of the iteration is instead fixed, then express your uncertainty as a range of available application functionality: “We’ll finish by 15 May, and the application will include these requirements, but probably not these requirements implemented as features”. When you have more uncertainty in your project planning, use bigger units (iterations, months, and then fiscal quarters).

5. Plan to replan frequently – If information used to plan the current project plan has now changed, incorporate those changed pieces of information into the current project plan. his will aloow the project plan to adapt and grow in response to changing conditions. This is an oportunity to show why Agile project plans are called Agile in the irst place. Ensure that the project team is always squarely aligned at the goal of delivery the maximum value to the organization.

6. Communicate progress and track progress of the project team – Keep the project’s primary stakeholders infomed of the progress of the project team by regularly publishing simple and easy to understand charts indicating the progress of the project team. Burndown and velocity charts are an excellent way todo this easily and simply.

7. Plan to learn from and adapt to an Agile project –

8. Plan requirements of the correct dimensions –

9. Prioritize requirements well – Work should progress on software requirements in such a manner as to maximize the entire value return of the project.

10. Base your project plans and estimates on reality –

11. Learn to Pad your schedules correctly – A software development team scheduled to within an inch of its life cannot progress efficiently. Do not plan on using 100% of an available resource or individual 100% of their available time. Do not over-schedule. Put some slack into you project plans and prevent project gridlock.

12. Create rolling lookahead plans for the project team’s use – With multiple teams performing work on a project, coordinate their work through the use of rolling lookahead planning. Looking ahead to allocate requirements to specific future iterations and spotting and planning of interteam dependencies is also enabled.


PHP for Beginners


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.


About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

%d bloggers like this: