What are the critical types of thinking that are necessary at each stage of a project? What might one look for in creating or picking the most effective team? What skills, in terms of how someone thinks, would provide the best "mixture"? Any suggestions would be helpful! Saving Changes...
I think one often overlooked or underappreciated type of thinking is Creative Thinking. All parties in the project need to be creative thinkers to be able to react, be flexible, and to solve issues that are common occurances in a project. Too often people feel that once the plan is created and in place and the designs are locked down, creativity goes out the window. Reality is quite different, and creative solutions to problems are always required. Saving Changes...
Anonymous
That is excellent insight. My thought is that there are really a few distinct types of thinking required in different phases of projects and project management. At the beginning you are right, it must be creative. Once the project has been thought of and initiated, it need to fit into "the business" and therefore strategic thining is required. Once the overall strategy is completed, the remainder of the project requires tactical thinking. What do you think? Saving Changes...
This is very interesting. I like Kevin's point: Creative problem solving ability is key in IS projects. The ability to react to problems and technical issues is important at all phases of the project. However, I feel that no one type of behavior is more valuable than other. We also need analysis, planning, and personal interaction to make the team work effectively. Simply stated, a creative solution to the problem isn't enough. You also have to know the down stream affects on other technologies, plans, estimates and even on the people and how they work together. Looking at any one aspect of behavior as "key" simply shifts the focus. A good team will exhibit diverse thinking, behavior and interaction. Saving Changes...
I agree entirely with both previous points. My point was not that creativity is the only thinking skill required, but is one that is largely overlooked. Leadership is the other, as without it one ends up being a project administrator, not manager. The best way to get people to fill out time reports, status reports, and the like to have them follow a respected and dynamic leader, who demonstrates and emphasizes the value of their contribution, not just forces reporting requirements or time tracking down their throats. Saving Changes...
Anonymous
Wow. This is great insight. I am curious to see if either of you (or anyone else that wants to respond) think that there are some types of thinking that are more important at various stages of the project than others. Saving Changes...
Ok, if I had to break it down, and I'm not sure that it is even that clean cut, I'd do so this way:
Planning and Initiation Phase - Strategic and High Level Thinking
Design Phase - Creative Thinking and Salesmanship (one I hadn't mentioned but enormously important during requirements negotiation during design)
Construction Phase - Creative Thinking (for resolving construction issues when designs are flawed)
QA & Deployment - Leadership leadership leadership. This is where the rubber hits the road or the you-know-what hits the fan. A truly great project manager here is like a captain of a ship in a storm. His or her crew will only respond to the time crunches, inevitable overtime, and pressure as well as he or she does.
Let me take a shot at what Kevin offered, using his phases.
1-P&I-Same, but maybe with some skepticism and pragmatism. How many of us get high level and miss the point of what the client was wanting
2-D-Same, but analytic skills come in here as well, again with skepticism and pragmatism. I think S&P might be a great way to think about analysis and design - why do we need this feature in/out; will it work this way if we use it.
3-C-Same, but again with S&P. Consistent thinking also comes into play. Why did these design defects escapt our design reviews? What other defects like this have we missed?
4-QA&D-If someone on the team remained skeptical and pragmatic throughout, quality control (i.e. testing) is a non-issue. Deployment becomes trivial because all the problems were removed early in the project.
By the way, these ideas are right from PSP and TSP, if you want to find out more. Check the SEI web site, or SEIR (through SEI). Saving Changes...
Anonymous
Excellent. So now, let me make one more query. What kind of thinking would you look to make up a project team? Each person could have different "thinking styles" or a make up of a few. I am talking in the ideal here. Saving Changes...
I taught a TSP-based class at RIT last quarter and got a really good sense of the fundamendal value of the team roles Watts Humphrey offers us there. If I were going to be doing a software development project anytime soon, I'd be thinking about these roles and goals and the thinking styles that go along with them. These are summarized from the TSPi book, which is a great resource even if you don't intend to use it with PSP engineers.
(From chapters 11 thru 15) Team Leader goals: - builds and maintains an effective team - motivates all team members to work aggressively on the project - resolves all issues team members bring to them - keeps project manager fully informed about team progress - perform effectively as the team's meeting facilitator
Development Manager goals: - produce a superior product - fully utilize the team members' skills and abilities
Planning Manager goals: - produce a complete, precise, and accurate plan for the team and for every team member - accurately report team status every week
Quality/Process Manager goals: - all team members accurately report and properly use TSPi process data - the team faithfully follows the TSPi quality plan and produces a quality product - all team inspections are properly moderated and reported - all team meetings are accurately reported and the reports put in the project notebook
Support Manager goals: - the team has suitable tools and materials to support its work - no unauthorized changes are made to baselined products - all the team's risks and issues are recorded in the risk-tracking system and reported each week - the team meets its reuse goals for the development cycle
Notice what these goals are dealing with - the issues that are often critical to a project but thought of as trivial when the project manager has to do them over and above all the 'real' project management tasks they have assigned to them. When the PM delegates these activities to a motivated team, I would expect a more successful project. If the team also happens to have PSP training and has developed the discipline to stay with the scripts under pressure, the results can be outstanding.
I think there might be a lot of people who went into project management because they were tired of having projects go south when issues like the ones above were neglected. Maybe if we trusted our teammates to take on some of these duties, we'd all be better off. These are technical management issues anyway, not project management issues. The technical team is probably qualified to do these things, if we admit to ourselves that we can't ignore them.
Now to the second part of the question - what 'thinking styles' go along with these roles.
Team manager - organized, natural leader, able to make the decisions that need to be made for the good of the project Development manager - best design skills of the group, but flexible enough to let other people actually implement the design, cooperative under pressure, willing to listen, encourages ideas from others Planning manager - another organizer, but one that can keep an eye on all the details in a nice way Quality/Process manager - more focus on the details, and maybe a little nitpicky, and able to back up from the data that is coming in to see the trends across problems Support manager - someone who likes to tinker with things and build tools for the team when necessary, possibly obsessed with configuration management, a generalist who often asks "could we make a more generic version of this that we could reuse elsewhere in the system" and "isn't this a little like the XYZ module that Jane was designing last week"
For more ideas, get the TSPi book or check out presentations on the SEI web site. Some of the better ones are on the SEI Repository site, which requires a free logon/password. It's well worth signing up. Saving Changes...
