Learning Project Management

Why do I want to learn Project Management?

There is no way I can escape projects in my life (even making dinner is a project of sorts) so I might just as well learn how to do projects well. The upside of this is that I will get better results in all areas of my life (yes, even cooking). I will be able to address things quicker, smarter, with less procrastination, and I will be able to get things done on time with better results (can't beat that). My ability to practice project management well will give me less stress, more fun, and more confidence.

Knowledge Construction

Here are the main ideas of project management:

1. Start with a need or desire for something (to have or to be done)
2. Create diamond to decide on goal for project (10 minutes)
   • Note: Goals have to be 3 things
   1. 1. Extremely motivating
      2. Challenging but attainable
      3. Well-defined; measurable
3. Using a diamond, quickly "decompose" project into Tasks (just enough Tasks to get started). (10 minutes)
   • Note: Each Task must
   1. 1. Have a goal
      2. Take 15-60 minutes to accomplish
4. Each Task has an Owner, and the load is balanced among members.
5. Complete Tasks
6. Meet regularly to
   1. Keep accountable on Tasks
   2. Solve problems
   3. Revise Tasks list (Iterate)
   4. Do SII's (Strength, Improvement, Insight)

At the end, Project Goals are hit, lessons have been learned, and documentation has been recorded.

Application

With this Knowledge Construction on how to tackle projects, I have been trying to apply project management in my every-day-life. I will illustrate my application of project management with an example from the school/professional area of my life (if have time I hope to post an additional example from the more personal area of my life).

Mechanical Engineering Project:

Applying project management in my current Mechanical Engineering project has been fairly straightforward, though difficult and in need of improvement. Our team has worked to have frequent meetings to keep each member accountable, we have used diamonds to define our goals, tasks, and to help with problem solving, and we have been careful to make sure that each task has an owner(s) and that the load is fairly balanced between members. Understandably, we have had to do a lot of iteration, even to the extent of changing our initial product idea. 

Strengths

Throughout this project, our team is done some things well:

• We meet frequently for short meetings.
  • We try to meet as often as once a day during the school week. This allowed us to keep close tabs on where we were and keep each member accountable.
• We assign owners for every task.
  • Every team member was great in volunteering for different tasks (I think it is a good indicator that the tasks are broken down well when no one is too scared to take them on). Giving each task an owner is extremely beneficial in that it creates fantastic accountability and the tasks seem to get done faster.
• We have made sure load is balanced among members.
• Thankfully for this project, balancing tour team has done a great job of balancing the task among the members (this is aided, I think, by the fact that with all of the tasks to be done written down and assigned owners, it is a breeze to assess how the work load is balanced). This lessens slacking, improves learning, and helps everyone have more fun.

Improvements

We have lots of areas we can improve in:

• Use more diamonds
  • We need to use diamonds as often as possible (we can only get better with practice). Diamonds are useful whenever ideas need generating, whether that's brainstorming the tasks to be done or figuring out what a good customer segment is, so we need to use them whenever we need ideas in a meeting. In the long run, this will give us more ingenuity, faster idea acquisition, and better ideas.
• Do more SII's as a team
• Doing SII's as a team will helps us grow immensely. We will be able to grow closer as a team, be more efficient, understand our strengths and weaknesses better, and have more fun. To do this we need to specifically set aside time during a project meeting to do an SII; at least one SII per project should be done (three or four would be better).

Here are a couple of pictures of my logbook.  They are notes of our meetings, and it might be worth noting the iteration that took place.  We started with a certain goal and product in mind, and after several meetings and discussions (and iterations), we had a different product and tasks.  Our project changed a lot.  

This picture is of my logbook right after deciding to switch from our first product (inventory counter) to our second product (power meter for bicycles).

(Part of my learning project management is taking extremely useful notes and documenting better.  As you can see, right now it is far from stellar.)

Lessons Learned
         The three most important things I have learned about project management deal with the importance of diamonds, tasks, and having regular meetings. 
         Diamonds are crucial in project management as an efficient way to get good ideas (i.e. for problem solving, task generating, etc).  Our tendency is to pick the first idea that pops into our heads; however, if we use diamonds to generate as many ideas an we possibly can, we get better ones in the end, making diamonds an important part of project management.
         I also learned about the necessity of breaking a project into well-defined tasks and giving each of those tasks an owner.  When we tried this out in our project meetings, the results were glorious.  Everyone knew exactly what they were doing and when they had to have their task done, so things got done quicker; and, for some reason, people helped each other out more, too.
         Lastly, having regular meetings helped our project management immensely.  It allowed us to have shorter meetings while still going over the necessary "stuff".  Additionally, it helped us get to know our team members better (an immeasurable bonus when you are trying to work together as a team).

       
        The three most important things I learned about the Learning Cycle is that: 1) not everyone learns the same way, 2) application is super important, 3) iteration is super important.

• Not everyone learns the same way
• As the Kolb learning cycle shows, everyone learns things a little bit differently, which is exciting to me because it helps me understand my team members better (as well as others in general). 
• Application is super important
• This is especially important to me because I know that unless I actually apply something, I am useless at remembering it for the future.
• Iteration is super important
• Although I very much dislike this part of the learning cycle, I understand its importance, since it is better to do something a number of times quickly, than to try to get it right the first time (much more stress).  This is definitely something that will take me a while to get.

Arduino Challenge Problem

Problem Statement


Make a servo rotate 180 degrees in one direction, then pause for half of a second and rotate back, pausing another half of a second then repeating.  At close to the 0 degree position (I chose the 1 degree position), a red light should turn on, and at the 180 degree position, a green light should turn on.

Key Facts

• if commands are important for making lights turn on at specific points
• for the servo wire, the orange connects to your digital control pin, the red connects to the +5 volts pin, the brown connects to the ground
• be wary of special servo functions

Solution

Hardware

Code

#include <Servo.h> 

 

Servo myservo;  // create servo object to control a servo 

                // a maximum of eight servo objects can be created 

 

int pos = 0;    // variable to store the servo position 

 

void setup() 

{ 

  pinMode(13, OUTPUT);

  pinMode(11, OUTPUT);

  myservo.attach(9);  // attaches the servo on pin 9 to the servo object 

} 

 

 

void loop() 

{ 

  if (pos = 1)                  // when servo is at 1 degree an led on pin 11 turns on 

{

  digitalWrite(11, HIGH);

  delay(500);

  digitalWrite(11, LOW);

}

  for(pos = 0; pos < 180; pos += 1)  // goes from 0 degrees to 180 degrees 

  {                                  // in steps of 1 degree 

    myservo.write(pos);              // tell servo to go to position in variable 'pos' 

    delay(15);                       // waits 15ms for the servo to reach the position 

  } 

  if (pos = 180)                    // when servo at 180 degrees, led on pin 13 turns on

  { 

 

  digitalWrite(13, HIGH);

delay(500);

  digitalWrite(13, LOW);

  }

  

  for(pos = 180; pos>=1; pos-=1)     // goes from 180 degrees to 0 degrees 

  {                                

    myservo.write(pos);              // tell servo to go to position in variable 'pos' 

    delay(15);                       // waits 15ms for the servo to reach the position 

  } 

  

} 

Problem Documentation

Author:  Austin Tanner 

(servo sketch primarily based off of "Sweep" by BARRAGAN <http://barraganstudio.com>)

Date Created:  11/25/2012

Growing My Performance in Collaboration

Defensive Reasoning

Defensive Reasoning is the “fight or flight” mode that the brain enters when a person is feeling judged or criticized, or even when they are simply not succeeding at their current task.  This often causes people to respond by becoming angry or defensive, and when their defensiveness or anger is pointed out, they often deny it.  Another reaction a person might have when in defensive reasoning “mode” is that, although they might not get angry or defensive, they may start blaming the situation or say something like, “I am just not cut out to be a swimmer”.  This is a problem because when a person enters this mode of thinking they stop learning effectively.  Their brain releases chemicals that shut down their “higher order of thinking”, effectively causing that person to stagnate and stop learning.  They have not yet leaned how to separate perceived criticism, judgment, failure, etc, from data that they can use to help them grow.  To overcome this problem, a person should start by recognizing when their brain enters the “defensive reasoning” mode.  Once the person recognizes defensive reasoning, they should accept the emotions that come from it and let them pass.  Ultimately, if a person is able to apply Critical Thinking to a situation and then use the SII method to improve his results, he will be able to avoid defensive reasoning.

The SII Process
The SII process is a three-step process:
1. Identify 2-3 of my strengths.
    a.    Name action
    b.    Explain how I did action
    c.    Explain why it benefited me
2. Identify 1-2 Improvements
    a.    Name action I will take in the future
    b.    Explain how I will do the action
    c.    Explain why it will benefit me
3. Identify 1-2 Insights
In this process, strength is considered a skill that I used that benefited me in what I just accomplished, an improvement is a skill that I will use in the future to benefit me, and an insight the light bulb that went on (i.e. new knowledge that I finally got).

My SII on Collaboration

Step 1.  Strengths > My top 2 strengths in Collaboration

#1 Tried to cut down on my criticism.
Name – cut back on criticism
How – Reminded myself that every idea is worth considering
Why – I have a natural instinct to always want to go with my idea, even though it is probably (most likely) not the best idea on the table.  My fellow team members are all geniuses and have REALLY great ideas, so it is to my benefit to listen to them.

#2 Made sure we are clear about duties between meetings.
Name – clear communication about duties between meetings
How – at the end of the meeting, wrapped up by re-clarifying duties and having each member state what they need to have accomplished before the next meeting.
Why – this improves team efficiency, shortens meeting times, and ensures that each member is doing their share of the work.

Step 2.  Improvements > Top improvement

#1 Cut back on how much I talk during meetings.
Name – Cut back on my talking during meetings.
How – Focus on tasks at hand, and follow an agenda so as not to get distracted.
Why – Improves team efficiency, doesn’t waste others’ time, keeps me from looking like a fool.

Step 3. Insight > Insight

#1 When I am in a team setting (or anywhere for that matter), I find that I often get into defensive reasoning and try to defend my ideas, even though I know that the other person is right and that my idea is wrong.  Thus, I am finally starting to understand the full effect that defensive reasoning has on me, and how to recognize when I am entering that “mode”.

Tech Transfer and Intellectual Property

       This past week I had the very special opportunity to attend a talk by Gaylene Anderson who is from the University of Idaho Tech Transfer.  She gave a very easy-to-listen-to, highly informative talk on how to protect intellectual property.  While she gave us information on patents, licenses, trade secrets, and tips and information on how the process of technology transfer works, there were a few things that stuck out as being especially useful to me right now.  These were things like: the things an idea (i.e. an invention) has to be in order for it to be patent-able, what to do when sharing your ideas with others, and knowing whom your customer is.
The first thing that stuck out to me as being pertinent to my current situation was when she talked about what an idea has to be in order for her to be able to file it for a patent.  Interestingly enough, the idea must be novel, useful, and non-obvious.  The first two made sense to me right away.  Obviously, if a new invention is not going to be novel or useful, it is probably not worth patenting.  However, the third stipulation, that of the idea being non-obvious, caught me slightly off-guard.  In my mind, I had always thought that it wouldn’t matter how obvious (i.e. if someone else in your profession looked at it would they be able to figure it out easily) of a thing it was as long as your invention was something novel and useful.  Knowing this gives me a much clearer idea of what I need to aim for when developing new products, and when deciding if an idea is worth patenting or not.
Sharing ideas with others is an extremely natural thing for people to do.  I know that if I have a new thing or idea, I just love telling others about it.  Knowing this, Gaylene Anderson gave us some tips on how to be able to share our ideas with others while keeping them safe from being stolen, etc.  By making the party I am sharing with sign a confidentiality agreement (even if it is only on a napkin), not only will they not be able to steal my idea, but also my disclosure of information will not be considered a “public disclosure” and I will not be required to file for a patent within 12 months.  This it invaluable to me because I love telling others about my work and designs, so having a way that I can do that without painting myself into a corner is going to be very useful.
Finally, Gaylene Anderson reminded us of the importance of knowing who my customer is.  She told numerous stories of products that were “cool”, but had no marketability because there was no customer base for them.  This is definitely an important point since Dr. Elger has been pointing it out a lot as well this semester.  Understandably, I can apply this idea in every product that I create.  Knowing who my customers are while I am building a product will not only allow me to create better products, but also more marketable ones.
Gaylene Anderson’s talk was incredibly helpful to me as an engineer who is excited about designing and inventing new things.

Designing an Experiment

             Experiment design is the process of systematically planning, executing, analyzing, and recording an experiment.  This process has many benefits ranging from making me much faster at running experiments to giving me the credibility I need on the job, in the laboratory, etc.  These benefits include things like helping me acquire accurate data (as apposed to theoretically driven math models), making me more confident in my data, giving me an easy way to openly share and explain my work to others, and providing my with the best way to learn engineering, i.e. using hands-on work to analyze and process real-world data. 

            How to actually “do” experiment design can be explained in several steps.  The first step is to find the “Why?” i.e. for what reason(s) am I doing this experiment.  This reason can range from validating a math model, to testing a design.  The second step is to use Knowledge Construction.  As its name indicates, Knowledge Construction is the process of acquiring information, specifically in looking for the best sources of knowledge available, understanding the knowledge, and applying it to my life.  Although not always used, step three is to make predictions on what will happen.  The fourth Step is the detailed process of figuring out exactly how I want to run my experiment and documenting my work.  When applying step four there are a few things I am looking for.  Initially, I want to set up and define the goals of my experiment (i.e. what am I measuring and how much data do I need?), then I need to generate ideas on how to measure my data, what can affect the results of my data, how will I calibrate my instruments, etc.  After I have a list of ideas, I need to select the best ones, make a step-by-step plan to execute them, and get my equipment ready for the experiment.  At this point we reach the fun part of experiment design.  In step five get to I execute the step-by-step plan created in the fourth step, process the data collected, and document the experiment in real-time.  Following this, I review my process and results and compare my findings with my original theory.  This is also a good time to go back and dig around some more in the literature.  Finally, step six is where I can loop back and run the process again, doing an iterative process to improve results, learning, and speed.

            A person can follow the correct experiment design procedure and still have skewed results simply because of their belief system, however.  A person who says he believes in science and data, but only uses what supports his beliefs and rejects the evidence that goes against them has an Alchemy belief system.  This is common simply because we like to be right.  In fact, it is a biological trait that, when we are challenged, our brains naturally want to kick into a “fight of flight” mode.  In contrast with Alchemy, people who hold the Scientific belief system believe that data and evidence will indicate what is most likely true.  Those who hold this latter view have to be skeptical of their own views, realizing that their interpretations of the data may not be correct.  This Scientific belief system is rare simply because of the natural tendency we have as human being to want to be right, whether or not it is supported by data.  Endorsing this rarer viewpoint, however, carries with it the benefits of better and quicker learning, and credibility.

            Here are some real-world examples of using this scientific method.  When learning about transistors and diodes if I can write down the fundamentals of how they work using semiconductors from memory or explain them to others I have clear evidence that I am grasping the concept.  If a thermometer I am designing using an Arduino and a thermocouple begins recording skewed temperatures I have data/evidence that my thermometer is not working correctly.  If a math model I am creating spits out values that are validated by experiments, I have data/evidence that my math model is most likely correct. 

              

Thermal Mug: Mug Project

The following situation is proposed, concerning the cooling of a liquid (in this case water) using ice.  

“Warm water (an idealization of beer or soda) is poured into a container (an idealization of a chilled mug) that has been placed in the freezer. The system (i.e. mug plus water) is allowed to reach thermal equilibrium.”   -learning4doing.com

When creating a math model to predict the final temperature of the water several steps should be taken.  The first step is defining the situation so that I understand clearly what the real problem is.  The second is defining in concrete terms what my goal is, i.e. what exactly is the math model supposed to do.  Once a goal is established I can move on to generating ideas on how to solve this problem.  In this particular situation I see that the law of conservation of energy can be applied.  This gives me the tools I need to create an algebraic equation to reach my goal.  The following pictures are of my hand-written math model.  

After creating my math model and programming my equation into Matlab, I found that my answers were not at all satisfactory.  Somewhere in my math model I made a mistake.  But that is the exciting part, because it is usually in our mistakes that we learn the most.  I will have to revisit this problem in a later post after I have found my mistakes.  My current Matlab script function is as follows:

 function finaltemp1

%finaltemp1 determines the final temperature of water in a glass after a

%certain amount of ice has been melted in it (this function assumes that

%the glass with water is a closed system)

Sw = 4.18; % specific heat of water (in Joules/grams*Kelvin)

Si = 2.09; % specific heat of ice (in Joules/grams*Kelvin)

Hfus = 333.9; % heat of fusion of ice (in kJ/kg)

syms m1 t1 m2 mi ti; 

ti = input('Enter initial temperature of ice (in Kelvin):'); 

mi = input('Enter mass of ice (in grams):');

t1 = input('Enter temperature of water before ice is added (in Kelvin):');

m1 = input('Enter mass of water before ice added (in grams):');

m2 = m1 +mi;

T2 = (Sw*m1*t1 - (Si*mi*(273.15 - ti) + (Hfus*mi)/1000 + Sw*mi*273.15)/(Sw*(m1+m2)));

T2c = T2 - 273.15;

disp('final temperature of water (in celcius)')

disp(T2c)

end

Temperature Measurement Assignment

11/2/2012

Temperature Measurement Assignment 

    

          As I continue further and further into my education to become a mechanical engineer, I often wonder, “What do I need to know in order to become an extraordinarily good (or at least a proficient) mechanical engineer?”  Recently I have begun learning some computer programming in my Mechanical Engineering 223 (Technology Design) class.  It is important for me to learn computer programming for a couple of reasons.  It gives me more tools to use when analyzing things, designing products, or operating mechanisms.  In the end this saves me enormous amounts of time and allows me to create much better products. 

          When contemplating how do design a sketch for the Arduino that would enable me to easily reach my goal of measuring and recording temperature measurements in three different scenarios, I decided that I would need to do some knowledge construction (i.e. finding the best source of knowledge out there, figuring out the knowledge, and applying it to my situation).  I did this by consulting our ARDX kit’s “Experimenter’s Guide for Arduino”, which gave me an already-designed sketch for recording temperature with an Arduino.  I also consulted Adafruit Tutorials as to their method for programming an Arduino to record temperature data.  This knowledge construction allowed me to create my own sketch, basing it off of the ARDX sketch, in a very short amount of time.  The most efficient and stress-free method for engineers to address problems is to use knowledge construction and build off of already-developed ideas (i.e. don’t “reinvent the wheel”).

The Arduino sketch that I developed to record temperature data is as follows:

/* A simple program to output the current temperature to the IDE's debug window 

 * This sketch has the ability to output temperature is celcius, 

 fahrenheit, or Kelvin, or any combination of the three.

 *  To activate the different temperature readings simply erase the 

 comment indicator(s) (i.e. * / and / * ) for the reading(s) you want

 */

//TMP36 Pin Variables

int temperaturePin = 0; //the analog pin the TMP36's Vout (sense) pin is connected to

                        //the resolution is 10 mV / degree centigrade 

                        //(500 mV offset) to make negative temperatures an option

/*

 * setup() - this function runs once when you turn your Arduino on

 * We initialize the serial connection with the computer

 */

void setup()

{

  Serial.begin(9600);  //Start the serial connection with the copmuter

                       //to view the result open the serial monitor 

                       //last button beneath the file bar (looks like a box with an antenae)

}

void loop()                     // run over and over again

{

  //the following prints temperature in celcius

 float temperature = getVoltage(temperaturePin);  //getting the voltage reading from the temperature sensor

 temperature = (temperature - .5) * 100;          //converting from 10 mv per degree wit 500 mV offset

                                                  //to degrees ((volatge - 500mV) times 100)

 Serial.println(temperature);                     //printing the result

 Serial.println("degrees Centigrade");

// the following prints temperature in fahrenheit

/* float temperaturef = getVoltage(temperaturePin);  // getting the voltage reading from the temperature sensor 

temperaturef = ((((temperaturef - .5) * 100)*1.8) + 32);  //converting from celsius to fahrenheit

 Serial.println(temperaturef);                        // printing the result

 Serial.println("degrees Fahrenheit");                 // printing label for value

*/

//the following prints temperature in Kelvin

/*float temperaturek = getVoltage(temperaturePin);    //getting the voltage from the temperature sensor

temperaturek = (((temperaturek -.5)*100) + 273.15);          // converting from celsius to kelvin

Serial.println(temperaturek);                    // printing the result

Serial.println("degrees Kelvin");               // printing label for value

*/

 delay(2000);                                     //waiting a second

}

/*

 * getVoltage() - returns the voltage on the analog input defined by

 * pin

 */

float getVoltage(int pin){

 return (analogRead(pin) * .004882814); //converting from a 0 to 1023 digital range

                                        // to 0 to 5 volts (each 1 reading equals ~ 5 millivolts

}

Recorded Data: 

Degrees in Celcius

Temperature of wall of cup filled with hot water  (data every 3 seconds)	Temperature of metal razor blade on ice cube (data every 2 seconds)	Temperature of heavy paper held over toaster (data every 2 seconds)
17.38 18.36 21.78 22.75 24.71 25.68 27.15 28.13 28.13 29.59 29.59 30.08 30.08 31.05 31.05 31.54 33.01 33.01 33.01 33.01 33.50 33.50 33.98 33.98 33.98 34.47 34.96 34.96	22.75 22.75 22.75 22.27 21.78 20.80 20.31 19.34 18.85 17.38 16.41 15.43 14.94 14.45 13.48 13.48 12.99 12.50 12.50 12.50 12.01 12.01 11.52 11.52 11.52 11.04 11.04 11.04	19.82 19.82 20.80 20.80 21.78 22.75 23.73 25.20 26.17 27.64 29.10 30.57 32.52 31.54 31.54 33.98 36.91 38.38 39.36 40.82 42.29 43.75 44.73 45.70 47.17

           

             Perhaps the most exciting feature of this sketch, which sets it apart from the ARDX code and the Adafruit sketch is its ability to measure temperature not only in Celsius (centigrade), but also in Fahrenheit and Kelvin.  All three print options are found in the loop section of the sketch, however currently the Fahrenheit and Kelvin options are deactivated by being turned into comments.  To activate them, one only has to delete the comment indicators (i.e. /* and */ ).  I chose to include these options since, as engineers, we often have to deal with all three different temperature, so having the option to record data in any one (or all) of different forms is extremely handy.

           

            In retrospect, there were some things I did well and some things that could be improved on.  As was mentioned earlier, using knowledge construction to help build my sketch allowed me to be efficient as well as lowering my stress level.  One thing that I could have done better, however, would have been to make a written plan of action, i.e. to write out my plan before executing it.  Although the benefits of having a written plan of action to follow have been clearly displayed in other projects and experiments, I didn’t take the time to do it on this project and suffered some because of it.