受託について

投稿者

投稿内容

Anthyhime: ぬし; 会議室デビュー日: 2002/09/10; 投稿数: 437

投稿日時: 2005-06-05 10:09

> 初めての仕事だと意気込みすぎて、必要以上に大量の資料を作成し、
> システムもサービスいっぱいの多機能にしてしまったことです。
> そこで一番の問題となっているのは、当初の見積には無い機能を
> 追加したのに、当初の見積のまま開発することになってしまったことです。

不要な資料と機能を減らすように顧客と交渉しましょう。
現状のスコープのまま開発を続けると完成が難しいことをその原因とともに顧客に
正しく伝えるべきです。減らせない場合は再見積もりして再度契約を結びましょう。
おそらく顧客の担当者も製品の完成を望んであるはずです。
msoさんと顧客の担当者の人間関係もあると思いますが、そこらでなんとか妥協点を
探るしかないのではないでしょうか。

[ メッセージ編集済み編集者: Anthyhime 編集日時 2005-06-05 10:10 ]

はづき: 会議室デビュー日: 2005/02/23; 投稿数: 5; お住まい・勤務地: 渋谷

投稿日時: 2005-07-04 16:25

msoさん

私もはじめてプロジェクトのリーダをした時は右も左もわからずに苦労したことを
思い出しました。
今はいろいろ参考となる書籍、情報も多いので参考にしながら頑張ってください。
とりあえず、いくつか具体的に参考になる情報をこちらに記載します。

①Webサイト：企業システム戦略の基礎知識

　＠ITのページなので呼んだことがあるかもしれませんが。。
　基本的にはシステムを導入する側の企業向けに記載をしているもの
　ですが、プロジェクトリーダとしての考え方や視点における重要な
　ポイントが記載されているのと、非常にわかりやすく書いてあるので
　読んでみて下さい

http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/index.html

②Webサイト：WBSサンプルとシステムタスク
　やはりシステムを導入する側の企業を主体に記載していますが、システム
　導入におけるポイントを記載しています。
　こちらのコンテンツの1つにWBSのサンプルがあります。

http://www.b-connect.co.jp/system/sys06_4.html

③書籍：世界一わかりやすいプロジェクト・マネジメント
　総合法令出版 ; ISBN: 4893468995
　
　いろいろなサンプルや図表もあり非常にわかりやすいです。
　社内でこういったことを体系的に教えてくれる人や講習などがない場合は
　これを1冊手元においておき、参照しながら進めるだけでも、まったく
　手探りで行うよりはよいでしょう

　アマゾンや楽天ブックなどで書籍名で検索すればヒットします

[ メッセージ編集済み編集者: はづき編集日時 2005-07-04 16:26 ]

mso: ぬし; 会議室デビュー日: 2003/12/04; 投稿数: 496; お住まい・勤務地: 宮城

投稿日時: 2005-08-09 00:19

msoです。

掲示板に書き込みをしてから、大夫時間がたっていますし、
あまりチェックしていなかったので、
はづきさんが書き込んでくれていたのに気づきませんでした。

書籍についてはまだ読んだことがないものがあるので、
とりあえずは立ち読みぐらいはしてみようと思います。

ちなみにプロジェクトマネージャとしてどうなってきたのか、
まだ自分ではわかりませんが少しずつではありますが回るようになったと思います。

近頃、わかってきた（勘違い？）気がするのですが、
顧客は上手に誘導していくのが良いと思ってきました。
自分の担当しているお客様はシステムについても、
コンピュータについてもあまりわかっていない方が多いです。
そのため、お客様にいろいろと聞いて提案をしてもらうよりも、
自分がやりやすく、お客様にもメリットのある形に誘導尋問をしています。
結果として、自分が辛くなることもありますが、８勝２敗程度の確率で、
楽をしている感じです。

何かわかったら（勘違い？）またここに書き込ませていただきます。

Jitta: ぬし; 会議室デビュー日: 2002/07/05; 投稿数: 6267; お住まい・勤務地: 兵庫県・海手

投稿日時: 2005-08-17 21:00

　最近、「プロジェクトの見える化」を目指しています。EVM とかは、ご存じです？まぁ、これも、使い方が難しいなぁ、、、と思っているのですけど。

　会社が初期投資を、どれくらい考えているか、と言うのも関係してくると思います。

　私がいるところは、１年で撤退してしまいました。しかし、原因を探っておかないと、「今のままではいずれ立ち行かなくなる」と思って始めたことなので、またやらなければならない時がくると思うんですよね。

　失敗から学ぶことがあれば、失敗は失敗だけに終わりませんよね。学べたものを「成果」として、次回に生かせばいいんじゃないでしょうか。
# 最初だから、かなり甘いこといってます

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-08-18 01:43

るぱんです。

成果物の定義をしてますか？
それが最低限度になると思います。
具体的には、サンプル・品質・記述量の基準等。

それを骨格に手が届く範囲の痒い所を掻いていくのがよろしいかと。。。
体系的にPJこなすのもいいけど、
軌道修正かけながらでは、体系に既に外れているわけですから
臨機応変で行く必要があるように思います。

あとは、全体像が埋没する傾向にあると思いますので、
「総論合意」を取ったものを明示していくといいと思います。

個別論ではうやむやに出来ますし。（卑怯）

でも、全員に効率的に動いてもらう為には、
やる気を引き出して、かつ自律駆動で動く。

そのためには目標を揃えに行かないと難しいでしょう。
PMの仕事はPJ全員に夢の有る全体像や未来像を見せる事だと思っています。

具体的な手法が一本見つかったらそれをビジョンで共有する
それを繰り返すしかないような・・・？

ほげた: ベテラン; 会議室デビュー日: 2002/05/08; 投稿数: 67; お住まい・勤務地: なごやん

投稿日時: 2005-08-19 02:28

PMってのは、監督です。
ゴールを決めて、それを達成するためにチームメンバをいかに効率よく稼動させるか。
そのために、目標の共有・合意形成は必須ですので、最終成果物や中間成果物の定義、
メンバの責任範囲を明確化してあげたり、作業環境を整えたり
問題を未然に防ぐためのリスク管理も重要です。

でも、一番大切なのは

引用:
るぱんさんの書き込み (2005-08-18 01:43) より: PMの仕事はPJ全員に夢の有る全体像や未来像を見せる事だと思っています。

ですかね。
この仕事なら頑張れる、という気を起こさせることが一番です。
＃このPMのためなら死ねる、とか。

PMP/PMBOK/CMM などいろいろ参考になるものはありますが、
どんなに成熟したプロセスでも、メンバのモチベーションが低ければ
うまくいかない気がします。
逆に、コミュニケーションとリーダシップが発揮できれば
ある程度なんとかなるんじゃないでしょうか。

«前のページへ 1|2

受託について

スキルアップ／キャリアアップ（JOB@IT）